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Abstract 

The  United  States  Air  Force  is  continually  researching  ways  to  reduce  costs 
associated  with  aircraft  maintenance  and  improve  operational  safety.  This  study  focuses 
on  creating  a  systems  engineering  process  to  develop  an  Integrated  Structural  Health 
Monitoring  System  (ISHMS).  The  overarching  process  was  then  applied  to  design  a 
conceptual  ISHMS  for  a  real-world  scenario  involving  the  F-15.  Sensor  selection, 
integration  and  testing  were  explored  in  detail  using  frequency  response  methods  to 
detect  structural  damage.  Testing  was  accomplished  using  a  simplified  structural 
specimen  with  Monitoring  &  Evaluation  Technology  Integration  System  (METIS)  disk 
nodes  attached  at  various  locations.  Two  different  METIS  disk  operation  modes  were 
utilized;  pulse-echo  and  pitch-catch.  Simulated  and  actual  damage  were  introduced  to 
the  specimen  allowing  comparison  between  baseline  and  damaged  tests.  Comparative 
analysis  validated  the  capabilities  of  frequency  response  sensors  to  detect  damage.  This 
analysis  demonstrates  that  structural  health  monitoring  systems  using  frequency  response 
methods  may  be  promising  in  the  aerospace  sector. 
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A  SYSTEMS  ENGINEERING  PROCESS  FOR  AN 


INTEGRATED  STRUCTURAL  HEALTH 
MONITORING  SYSTEM 


I.  Introduction 

This  chapter  introduces  the  background  work  that  was  accomplished  by  a 
previous  thesis  and  briefly  describes  the  proposed  approach  as  well  as  the  problem  and 
purpose  of  this  thesis. 

1.1  Background 

A  thesis  titled  “A  Systems  Engineering  Approach  To  Integrated  Structural  Health 
Monitoring  For  Aging  Aircraft”  was  completed  in  March  2006  by  Captain  Allan  P. 
Albert,  Captain  Efstathios  Antoniou,  Captain  Stephen  D.  Leggiero,  Major  Kimberly  A. 
Tooman,  and  Captain  Ramon  L.  Veglio.  That  thesis  investigated  a  systems  engineering 
approach  “to  the  development  and  implementation  of  a  cost-effective,  near  real-time, 
integrated  structural  health  monitoring  system  on  aircraft  that  did  not  have  such  a  system 
in  place  [1].”  The  thesis  accomplished  two  primary  tasks.  The  first  task  was  the 
development  of  an  Integrated  Structural  Health  Monitoring  System  (ISHMS)  Systems 
Engineering  (SE)  design  process.  This  was  accomplished  by  providing  functional 
architecture  products  which  can  be  used  “to  help  identify  the  top-level  operational 
concept  and  stakeholder  requirements  of  an  ISHMS  for  a  generic  aging  aircraft.  The 
second  task  was  to  demonstrate  the  potential  cost  benefits  of  installing  an  ISHMS  on  an 


1 


aging  aircraft.  The  subject  of  the  research  was  the  Coalition  Air  Force’s  (CAF)  A-37 
aircraft.  The  authors  accomplished  the  first  task  by  following  the  SE  Vee  Model  [2]  to 
define  the  system  level  design  problem  and  then  developing  the  functional  system 
architecture  following  the  Department  of  Defense  (DoD)  Architecture  Framework 
[5,6,7].  To  accomplish  the  second  task,  the  authors  created  mathematical  simulations 
using  data  from  the  CAF  A-37  and  showed  that  installing  an  ISHMS  can  reduce 
maintenance  inspections  while  maintaining  safety. 

1.2  Proposal 

Using  the  March  2006  thesis  as  a  starting  point,  this  thesis  seeks  to  continue  and 
build  upon  the  work  accomplished  prior.  This  thesis  will  seek  to  apply  systems 
engineering  to  develop  an  ISHMS  for  any  generic  aircraft.  This  will  be  accomplished  by 
further  development  of  architecture  products,  including  physical  architectures.  In  order 
to  verify  and  validate  the  architecture  products,  the  thesis  group  sought  to  apply  the 
processes  in  the  development  of  a  prototype  ISHMS.  The  ultimate  goal  is  that  when  used 
along  with  the  March  2006  thesis,  the  reader  will  have  a  well  defined  SE  process  along 
with  architecture  products  that  the  reader  can  use  to  guide  the  development  of  an  ISHMS 
for  their  particular  application. 

1.3  Problem  and  Purpose  Statement 

Since  the  work  accomplished  by  March  2006  thesis  team  concentrated  on  aging 
aircraft,  in  particular  the  CAF’s  A-37,  the  challenge  for  our  thesis  team  was  to  take  what 
was  already  done  and  to  further  expand  upon  that  work  so  that  it  can  be  adapted  and 
applied  to  any  aircraft  that  may  benefit  from  having  an  ISHMS  installed.  In  this  thesis 
the  group  wanted  to  accomplish  several  tasks  in  order  to  achieve  the  previously  stated 
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goal.  The  first  task  was  to  continue  the  systems  engineering  process  in  the  development 
of  functional  and  physical  architectures  to  complement  the  architectures  in  the  previous 
thesis.  Secondly,  we  executed  the  processes  and  architectures  in  the  development  of  a 
prototype  ISHMS  in  order  to  verify  and  validate  the  processes  and  architectures.  The 
third  task  was  to  use  what  we  learned  from  the  development  and  iteratively  refine  those 
processes  and  architectures. 

1.4  Problem  Focus 

Although  the  thesis  group  is  designing  a  SE  process  and  architecture  that  are 
generic  enough  to  be  used  to  design  an  ISHMS  for  any  particular  problem,  from  the 
outset,  the  group  wanted  to  select  a  real  world  problem  in  which  the  research  could  be 
focused.  This  would  enable  the  group  to  ultimately  apply  and  test  a  possible  solution  that 
was  designed.  This  process  began  by  contacting  the  F-15  maintenance  depot  at  Robins 
AFB  in  Georgia  to  ask  them  what  types  of  structural  problems  they  experience  that 
would  benefit  from  an  ISHMS.  This  initial  contact  led  to  the  thesis  group  making  a  trip 
to  the  F-15  maintenance  depot,  where  engineers  and  maintainers  provided  hands-on 
experience  with  several  structural  issues  that  the  F-15  was  currently  experiencing.  The 
group  was  presented  with  two  promising  structural  problems.  The  first  dealt  with  a 
structural  issue  in  the  wing  attach  lug,  and  the  second  dealt  with  a  bulkhead  in  front  of 
the  jet-fuel  starter  bay.  Of  the  two  problems  presented,  the  group  selected  the  problem  in 
which  one  of  the  F-15  bulkheads  was  experiencing  an  unexpected  crack.  The  group 
selected  the  problem  due  to  many  favorable  circumstances.  For  example,  the  structure  is 
critical  to  flight  safety.  Since  the  bulkhead  is  one  of  the  primary  structural  elements  in 
dispersing  stresses  from  the  wings,  a  failure  of  the  bulkhead  can  be  catastrophic  and 
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result  in  the  loss  of  an  aircraft.  Accessibility  to  the  problem  area  was  another 
consideration  in  choosing  the  problem,  and  although  an  ISHMS  would  be  most  useful  in 
difficult  to  reach  areas,  for  the  purpose  of  this  research  the  group  wanted  an  area  that 
would  be  easy  to  access.  An  additional  consideration  in  the  decision  is  the  uniqueness  of 
the  problem.  To  date,  there  has  been  only  one  known  F-15  aircraft  to  experience 
cracking  in  this  bulkhead.  This  crack  greatly  concerned  the  engineers,  as  the  bulkhead 
cannot  be  repaired  due  to  its  material  and  design.  To  replace  the  bulkhead  on  a  single  F- 
15  would  take  a  great  number  of  personnel,  hours,  and  millions  of  dollars. 

Once  the  group  selected  the  F-15  bulkhead  problem  to  focus  the  effort,  the  group 
began  working  towards  a  possible  ISHMS  solution  for  the  specific  problem  at  hand. 
Simultaneously,  the  group  began  working  on  the  SE  process  and  architectures.  An 
important  part  of  an  ISHMS  solution  is  the  sensor  selection,  and  from  the  various 
technologies  currently  available  the  group  was  guided  towards  methods  using  Lamb 
waves.  The  specific  technology  that  the  group  was  guided  to  use  was  the  Monitoring  & 
Evaluation  Technology  Integration  System  (METIS)  sensor.  There  were  several  reasons 
that  led  to  the  selection  of  the  METIS  sensor  as  part  of  the  research.  One  reason  was  that 
there  were  others  individuals  at  the  Air  Force  Institute  of  Technology  (AFIT)  as  well  as 
Air  Force  Research  Lab  (AFRL)  studying  the  Lamb  wave  technology  that  had  yielded 
promising  results  [28].  Another  reason  was  that  the  METIS  sensor  operating 
specifications  were  suited  to  use  for  application  on  the  F-15  bulkhead  problem.  The 
METIS  sensor  also  came  in  an  easy  to  use  housing  where  actuator  and  sensing 
mechanisms  were  encased  in  a  complete  unit.  The  entire  unit  is  then  bonded  to  structural 
surfaces  using  simple  epoxy. 
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Figure  1.1:  Pictures  of  F-15  Bulkhead  With  Crack  Flighlighted  For  Detail 
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II.  Structural  Health  Background 


This  chapter  discusses  background  and  some  current  approaches  of  integrated 
structural  health  monitoring.  Included  is  a  discussion  of  the  approach  that  was  studied 
for  this  thesis. 

2.1  Structural  Health  Background 

Structural  health  monitoring  is  an  important  part  of  any  maintenance  program  in 
which  the  safety  and  perfonnance  of  the  system  is  dependent  on  the  integrity  of  the 
structure.  Having  an  integrated  structural  health  monitoring  system  installed  on  an 
aircraft  would  provide  numerous  benefits.  For  example,  a  system  could  potentially 
decrease  the  frequency  of  required  inspections,  which  translates  into  cost  savings.  In 
addition,  another  benefit  is  the  added  safety  margin  that  a  system  would  give  the  user. 
Although  there  are  ISHMS  being  used  in  aircraft  today,  these  systems  are  not  as  robust  as 
other  monitoring  systems  used  in  other  areas  of  the  aircraft.  For  example,  the  avionics  or 
engine  monitoring  systems  are  much  more  robust  in  terms  of  being  able  to  provide  real 
time  data  or  warnings  to  the  operators.  Current  integrated  structural  health  monitoring 
methods  used  in  aircraft  are  primarily  limited  to  two  methods;  First,  the  collection  of 
flight  data  for  use  in  trend  analysis  and  fatigue  life  analysis,  and  second,  the  use  of 
sensors,  such  as  strain  gauges,  to  collect  structural  data  for  material  strength  analysis. 
Aircraft  structures  are  continually  being  pushed  to  their  limit  which  leads  to  an  ever 
increasing  need  for  advanced  ISHMS  capable  of  accurately  detecting  and  monitoring 
structural  damage  and  quickly  providing  useful  data  to  the  maintainers  or  operators. 
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2.2  Current  Methods 


A  great  deal  of  research  is  being  done  into  various  detection  and  monitoring 
technologies  and  their  application  in  structural  health  monitoring.  Traditional 
nondestructive  methods  used  in  structural  crack  detection  such  as  visual,  fluorescent 
dyes,  eddy  current,  and  ultrasonic  inspections  are  being  joined  by  new  methods  as 
technology  advances  such  as  methods  using  Lamb  waves.  Individuals,  companies,  and 
organizations,  including  academic  and  government,  are  continually  researching  advanced 
technologies  that  can  be  used  to  monitor  and  detect  structural  damage.  Equally  important 
is  being  able  to  package  these  technologies  into  a  system  that  is  modular,  capable  of 
being  adapted  to  a  variety  of  applications,  easy  to  operate,  and  has  a  high  reliability  and 
accuracy  of  detection.  One  such  technology  is  the  METIS  which  was  studied  as  part  of 
this  thesis  as  a  possible  ISHMS. 
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III.  System  Architectures 


This  chapter  introduces  the  ISHMS  architectures  used  to  create  a  generic  process 
for  the  integration  of  an  ISHMS  onto  an  aircraft.  The  process  was  created  using  the  DoD 
Architectural  Framework  process.  The  ISHMS  process  begins  with  the  requirements 
generation  process  and  is  completed  with  the  operation  of  a  system. 

3.1  ISHMS  Architectures 

In  this  section,  architecture  products  will  be  presented  that  demonstrate  the 
development  of  an  ISHMS.  The  products  were  created  using  Popkin’s  System  Architect 
software.  The  thesis  group  chose  to  develop  architectures  as  a  method  to  understand  all 
the  elements  necessary  to  develop  the  overall  system.  The  group  followed  the  generic 
six-step  process  presented  in  DoD  Architecture  Framework  Version  1.0  [6].  This 
framework  is  presented  in  figure  3.1 

CD 


Determine  the 
intended  use  of 
the  architecture 


CD _ CD _ CD 


Determine  I  Determine 

characteristics  I  and  prod 

to  be  captured  I  tobebii 


Figure  3.1:  Generic  Six-Step  Architecture  Process 


Determine  the 
scope  of 
the  architecture 


3.1.1  Six  Step  Architecture  Process 

The  first  step  in  the  six-step  architecture  process  was  to  determine  the  intended 
use  of  the  architecture.  The  thesis  group  decided  to  build  the  architecture  as  a  method  to 
present  the  process  of  creating  an  ISHMS.  This  process  would  include  everything 
needed  from  requirements  definition  all  the  way  through  an  operational  system.  The 
second  step  in  the  process  was  to  detennine  the  scope  of  the  architecture.  In  order  to 
understand  the  scope  of  the  project,  the  group  needed  to  determine  what  the  scope  of  the 
ISHMS  would  be.  The  group  decided  that  the  ISHMS  would  be  designed  for  a  specific 
aircraft  structural  problem.  The  purpose  of  the  system  is  to  give  post-mission  feedback 
on  the  current  status  of  that  specific  structural  area.  This  technology  gives  the  user  the 
capability  to  decrease  the  inspection  burden  and  frequency  at  that  particular  area.  The 
third  step  of  the  process  was  to  determine  the  characteristics  to  be  captured.  The  group 
decided  that  in  addition  to  capturing  the  requirements  to  create  an  ISHMS,  we  would  also 
build  a  physical  architecture  and  then  use  that  architecture  to  operate  an  actual  system. 
This  operation  would  give  us  the  capability  to  determine  an  operational  concept  for  how 
the  system  might  be  used.  The  fourth  step  in  the  process  was  to  determine  the 
architecture  products  to  be  built.  The  group  decided  that  the  following  architectures 
would  be  built:  AV-1,  AV-2,  OV-1  and  OV-5.  These  products  would  give  us  the 
diagrams  needed  to  depict  the  process.  The  fifth  step  in  the  process  was  to  gather  and 
build  the  requisite  products.  The  products  will  be  presented  in  the  following  section. 
Finally,  the  sixth  step  of  the  process  was  to  use  the  architecture  for  its  intended  purpose. 
The  thesis  group  accomplished  this  by  using  the  architecture  to  create  an  actual  structural 
health  monitoring  system.  This  step  is  described  in  section  3.2  and  section  4. 
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3.1.2  All-  Views  Architectures 


The  first  products  required  by  DoDAF  are  the  AV-1  and  AV-2,  which  are  textual 
descriptions  of  the  problem.  The  AV-1  serves  to  define  the  problem  and  communicates 
the  scope  of  the  problem.  The  AV-1  is  depicted  in  Figure  3.2.  The  AV-2  is  also  known 
as  the  Integrated  Data  Dictionary,  and  is  essentially  a  glossary  of  the  terms  used  in  the 
architecture  products.  The  AV-2  is  presented  in  Appendix  A. 


Identification 

Architecture  Title:  ISHMS  Life  Cycle  Process 
Architects:  AFIT  GSE-07M,  ISHMS  Thesis  Group 

Purpose 

Problem  Description:  Many  fatigue  critical  areas  exist  on  today’s  aircraft  in 
locations  that  are  time  consuming  and  difficult  to  access.  An  integrated  structural  health 
monitoring  system  provides  the  ability  to  detect  structural  damage  in  near  real-time 
while  greatly  reducing  the  need  for  inspections  and  flight  restrictions. 

Purpose:  to  apply  systems  engineering  approaches  to  define,  design,  install 
and  operate  an  ISHMS. 

Scope:  This  architecture  depicts  the  development  and  operation  of  an  ISHMS. 


Figure  3.2:  AV-1  Architecture 


3.1.3  Operational  Architectures 

3. 1.3.1  OV-1:  Archi-toon.  The  OV-1  (Figure  3.3)  was  developed  by  the 
thesis  group  in  order  to  give  a  portrayal  of  the  entire  system  from  a  high  level.  Although 
the  architecture  supports  a  generic  ISHMS,  the  thesis  group  used  a  picture  of  an  F-15  in 
the  background  since  the  specific  problem  the  group  explored  was  for  an  F-15  structure. 
The  diagram  begins  with  the  structure  of  interest  shown  on  the  left  hand  side.  The 
structure  interacts  with  the  sensor  shown  in  the  bottom  left  via  a  lightning  bolt.  The 
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lightning  bolts  represent  a  generic  form  of  interaction.  The  sensor  then  sends  its  data  to  a 
software  program  shown  on  the  bottom  right  and  the  software  is  then  used  to  generate 
maintenance  action.  Finally,  on  the  far  right  side  of  the  diagram,  maintainers  are 
performing  the  recommended  action  on  the  aircraft. 


Figure  3.3:  OV-1  Architecture 


3. 1.3. 2  OV-5:  Operational  Activity  Diagram.  The  next  architecture  is  the 
OV-5,  also  known  as  the  operational  activity  model  or  IDEFO.  The  IDEFOs  presented 
show  the  functional  decomposition  of  the  system  as  well  as  the  inputs,  controls,  outputs, 
and  mechanisms  (ICOM)  for  each  of  the  functions. 
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The  thesis  team  began  the  architecture  development  by  first  defining  what  the 
main  purpose  of  the  activity  model,  which  is  to  provide  generic  systems  engineering 
process  for  an  ISHMS.  This  purpose  was  then  converted  into  the  overarching  activity  of 
monitoring  structural  health,  which  is  shown  on  the  context  diagram  in  Figure  3.4. 
Moving  down  from  this  top-level  function,  the  process  of  monitoring  structural  health 
was  decomposed  to  the  bottom-level  functions  as  will  be  shown  in  the  following 
architecture  products. 

The  first  step  after  determining  the  context  diagram  activity  was  to  decompose  the 
function  into  four  major  functions  that  need  to  be  performed  in  order  to  develop  an 
ISHMS.  These  four  functions  are;  Define  ISHMS  Requirements,  Design  ISHMS,  Install 
ISHMS,  and  Operate  ISHMS  (Figure  3.5).  At  this  point  it  is  worth  mentioning  the  point 
of  departure  from  the  previous  AFIT  thesis  group.  The  previous  thesis  focused  primarily 
on  how  to  define  the  ISHMS  requirements.  This  thesis  will  iterate  the  architecture 
further  and  will  include  requirement  definition  as  one  of  the  four  top  level  functions,  but 
then  will  demonstrate  how  those  requirements  are  then  used  to  design,  install  and  operate 
the  system. 

The  first  step  in  creating  an  ISHMS  would  be  to  define  the  requirements.  The 
thesis  team  decomposed  the  requirements  definition  activity  into  the  following: 

Determine  Monitoring  Requirements,  Determine  Data  Collection  and  Processing 
Requirements,  Determine  Operational  Requirements,  and  Determine  Maintenance 
Requirements.  (Figure  3.6).  The  monitoring  function  includes  all  decisions  about  the 
sensors  used  in  the  system.  The  data  collection  and  processing  function  deals  with 
decisions  regarding  data  acquisition,  handling,  and  processing.  Next,  the  operational 
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function  captures  user  preferences  regarding  the  actual  operational  usage  of  the  ISHMS. 
Finally,  the  maintenance  function  deals  with  maintaining  the  ISHMS  system. 
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Figure  3.4:  Context  Diagram 
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Figure  3.5:  A-0  Architecture  -  Decomposition  of  Monitor  Structural  Flealth 
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Figure  3.6:  A- 1  Architecture  -  Decomposition  of  Determine  ISHMS  Requirements 
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Next,  the  monitoring  function  was  decomposed  further  to  aid  in  the  user  selecting 
appropriate  sensors  for  the  application  (Figure  3.7).  The  monitoring  function  was 
decomposed  into  three  functions.  The  first  function  is  to  determine  sensor  properties.  It 
is  critical  in  an  ISHMS  to  first  decide  what  type  of  sensors  will  be  utilized,  and  what 
properties  they  possess.  Properties  such  as  frequency,  sampling  rate  and  amplitudes  must 
be  detennined  before  sensor  location  and  quantity  can  be  chosen.  Once  the  sensor 
properties  are  known,  this  information  is  input  into  the  next  two  functions;  determine 
sensor  location  and  determine  sensor  quantity.  These  three  pieces  of  information  form  the 
basis  of  the  monitoring  requirements.  Next,  the  data  collection  and  processing  function 
was  decomposed  (Figure  3.8).  The  thesis  group  detennined  that  three  things  would  have 
to  happen  to  the  data  that  was  gathered  from  the  sensors.  First,  it  needs  to  be  stored,  so 
that  it  can  be  recalled  when  needed.  Second,  the  data  needs  to  be  processed.  Processing 
includes  basic  formatting  of  the  data  into  a  usable  format.  Third,  the  data  needs  to  be 
analyzed.  Analysis  consists  of  specially  trained  engineers  examining  the  data  and 
making  recommendations  on  the  dispensation  of  the  structural  member.  These  three 
functions  become  the  activities  in  the  decomposition  of  the  data  collection  and  processing 
function.  Next,  the  operational  requirements  function  was  decomposed  (Figure  3.9). 

Key  operational  requirements  that  were  identified  were  size,  temperature  and  vibration. 
These  three  items  are  particularly  important  on  modern  aircraft.  Each  of  these  areas 
became  an  activity  on  the  decomposition.  Additionally,  this  stage  is  ideal  for  creating  a 
concept  of  operation  (CONOPS).  This  CONOPS  will  describe  in  detail  the  manner  in 
which  the 
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Figure  3.7:  A-l  1  Architecture  -  Decomposition  of  Determine  Monitoring  Requirements 


18 


_  4— < 

X  00 


Figure  3.8:  A-12  Architecture  -  Decomposition  of  Determine  Data  Requirements 
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Figure  3.9:  A- 13  Architecture  -  Decomposition  of  Determine  Operational  Requirements 
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ISHMS  will  be  used.  It  will  answer  questions  such  as:  how  often  a  test  is  performed, 
what  conditions  are  required  in  the  hanger  as  a  test  is  performed,  etc.  Finally,  the 
maintenance  requirements  function  was  decomposed  (Figure  3.10).  Maintenance  was 
broken  up  into  four  key  areas.  First,  with  accessibility,  it  is  important  to  detennine  how 
accessible  the  ISHMS  should  be.  Space  is  a  premium  in  modern  aircraft,  and  in  many 
cases,  certain  areas  are  very  inaccessible.  Second,  durability  needs  to  be  considered,  as 
an  aircraft  tends  to  be  a  harsh  environment.  Third,  reliability  deals  with  the  probability 
that  a  component  will  not  malfunction.  Since  an  ISHMS  will  dictate  the  amount  of 
maintenance  that  will  be  performed  on  a  specific  structure,  it  is  important  that  the 
reliability  of  the  system  is  high.  Finally,  the  maintainability  of  the  system  relates  to  how 
easy  it  is  to  repair  when  it  does  malfunction.  Ideally,  the  system  will  be  easy,  cheap  and 
quick  to  fix.  These  maintenance  functions  represent  the  types  of  capabilities  that  an 
ISHMS  should  demonstrate.  They  may  not  represent  all  of  the  maintenance  functions 
that  are  necessary  for  a  particular  system. 

After  defining  the  ISHMS  requirements,  the  next  function  in  the  A-0  diagram  is 
design  ISHMS.  The  outputs  from  the  define  requirements  function  primarily  flow  into 
this  box,  and  are  transformed  by  the  design  function  into  ISHMS  plans.  The  thesis  group 
decomposed  the  design  function  into  three  main  components  that  need  to  be  designed 
(Figure  3.11).  They  are  the  sensors,  the  data  collection  unit,  and  the  data  processing 
software.  Each  of  these  activities  are  triggered  by  their  respective  requirements.  Upon 
design  completion,  the  system  can  be  drawn  up  into  complete  ISHMS  plans.  These  plans 
can  then  be  used  to  acquire  the  hardware  and  software  necessary  to  implement  the 
system. 
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Figure  3.10:  A-14  Architecture  -  Decomposition  of  Determine  Maint.  Requirements 
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Figure  3.11:  A-2  Architecture  -  Decomposition  of  Design  ISHMS 
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After  the  system  design  is  complete,  it  can  be  installed  on  an  aircraft.  The 
installation  function  is  the  third  activity  on  the  A-0  diagram.  The  install  function  is 
decomposed  into  four  functions  (Figure  3.12).  Similar  to  the  design  activity,  the  install 
function  includes  sensors,  data  collection  and  software;  however  the  fourth  function 
introduces  training  for  the  engineers.  The  engineer  requirements  enter  this  diagram  and 
trigger  the  training  for  the  engineers.  The  outputs  from  each  of  these  functions  combine 
together  to  form  a  fully  operational  ISHMS. 

Finally,  the  last  function  on  the  A-0  diagram  is  the  operate  ISHMS  function.  This 
function  is  where  the  structural  health  monitoring  actually  takes  place.  Operate  ISHMS 
is  decomposed  into  four  functions  (Figure  3.13).  These  four  functions  are  then  each 
decomposed  further  to  provide  added  insight  into  the  system  operation. 

The  first  function  is  Collect/Store  data.  This  function  is  decomposed  into  two 
functions,  Collect  Data  and  Store  Data  (Figure  3.14).  The  Collect  Data  function  is 
triggered  by  a  test  initiation.  In  practical  terms,  when  an  aircraft  has  completed  a 
mission,  part  of  the  post-flight  checks  will  be  for  a  maintainer  to  plug  into  the  system  and 
run  a  structural  health  test.  This  is  equivalent  to  the  test  initiation.  When  the  test  is 
complete,  a  message  will  be  sent  to  the  processing  software  stating  that  the  test  is 
complete,  while  sending  the  raw  data  to  the  storage  unit.  The  software  will  then  request 
the  data  to  be  transferred  triggering  the  store  data  function  to  release  its  data.  The  raw 
data  is  then  sent  on  to  the  second  function,  Process  Data.  In  this  function,  the  data  is 
formatted  into  useful  information.  It  may  be  converted  into  charts  or  tables,  and  is 
checked  for  errors. 
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Figure  3.12:  A-3  Architecture  -  Decomposition  of  Install  ISHMS 
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Figure  3.13:  A-4  Architecture  -  Decomposition  of  Operate  ISHMS 
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Figure  3.14:  A-41  Architecture  -  Decomposition  of  Collect/Store  Data 
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The  Process  Data  function  is  decomposed  into  four  functions  (Figure  3.15).  The 
first  function  is  Compile  Flight  Data.  In  this  function  the  raw  data  is  correlated  with  the 
flight  parameters  of  the  particular  mission  to  ensure  that  the  data  makes  sense.  It  also 
checks  the  data  for  errors.  This  filtered  data  is  then  sent  on  to  the  next  three  functions 
simultaneously.  In  the  first  of  these  functions,  Run  Mission  Processing,  the  data  is 
pieced  together  with  the  mission  parameters.  Trends  such  as  g’s,  speeds,  and  number  of 
takeoff  and  landings  are  reported  with  the  data  for  use  in  trend  analysis.  In  the  second  of 
these  functions,  Run  Aircraft  Historical  Processing,  the  data  is  compared  with  other  data 
from  the  aircraft  history.  This  will  give  the  analysis  engineer  a  history  of  the  aircraft’s 
structural  problems.  Again,  this  data  can  be  used  in  trend  analysis  to  determine  if 
something  specific  is  causing  the  structural  problems  over  time.  Finally,  in  the  third  of 
these  functions,  Run  Fleet  Historical  Processing,  the  data  is  compared  to  other  aircraft  in 
the  fleet.  This  is  used  to  detennine  if  a  problem  is  an  isolated  incident  for  a  particular 
aircraft,  or  if  it  is  a  consistent  problem  for  the  type  of  aircraft.  This  data  is  then  compiled 
and  output  to  the  next  function  in  the  form  of  an  Aircraft  Structural  Health  Report. 

The  third  function,  Analyze  Data  (Figure  3.16),  is  where  the  engineers  examine 
this  report  and  make  their  recommendations.  This  function  is  decomposed  into  five 
functions.  The  first  three  functions  are  all  different  forms  of  analysis  done  by  the 
engineers.  The  data  is  first  analyzed  to  determine  if  a  structural  health  problem  is 
present.  The  data  is  then  run  through  trend  analysis  software  to  determine  if  any  trends 
are  developing  in  the  aircraft  or  in  the  fleet.  Finally,  a  detailed  analysis  is  accomplished 
if  a 
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Figure  3.15:  A-42  Architecture  -  Decomposition  of  Process  Data 
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Figure  3.16:  A-43  Architecture  -  Decomposition  of  Analyze  Data 
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structural  problem  is  found.  In  this  function,  the  size,  location,  and  criticality  of  the 
damage  are  reported  in  as  much  detail  as  possible.  These  analysis  results  are  compiled 
and  then  sent  on  to  the  Recommend  Action  function.  In  this  step,  the  engineer  uses  all 
resources  at  hand  to  make  a  recommendation  on  the  issue  at  hand.  This  recommendation 
may  be  to  do  nothing,  or  to  inspect  or  repair  the  area,  or  to  place  a  flight  restriction  on  the 
aircraft  or  fleet.  Finally,  in  the  last  function,  Determine  System  Health  Performance,  the 
engineers  use  the  data  to  make  a  determination  of  the  health  of  the  actual  structural  health 
monitoring  system. 

Finally,  the  fourth  function  is  to  Utilize  Results  (Figure  3.17).  This  function  is 
decomposed  into  four  functions.  The  first  function  is  Generate  ISHMS  Maintenance 
Action.  This  function  is  triggered  by  the  System  Health  Report  from  the  analysis 
function.  If  a  determination  is  made  that  the  ISHSMS  is  not  performing  adequately,  then 
maintenance  will  be  perfonned  on  the  ISHMS  to  return  the  system  to  full  operating 
capability.  The  second,  third  and  fourth  functions  are  all  different  types  of  maintenance 
action  on  the  specific  aircraft  or  fleet.  These  actions  may  include  new  inspection 
requirements  or  shorter  inspection  intervals,  new  aircraft  or  fleet  flight  restrictions,  or 
maintenance  actions  on  the  specific  structure  of  the  aircraft.  Upon  completion  of  any  of 
these,  the  final  output  of  the  system  is  a  Completed  Structural  Health  Maintenance 
Action.  At  this  point,  the  aircraft  is  declared  ready  for  nonnal  operation,  subject  to  any 
new  inspection  intervals  or  flight  restrictions,  and  the  structural  health  monitoring 
process  is  complete. 
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Figure  3.17:  A-44  Architecture  -  Decomposition  of  Utilize  Results 
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3.2  Architecture  Instantiation 


After  the  architecture  had  been  completed,  the  thesis  group  wanted  to  use  it  to 
guide  them  in  the  creation  of  a  prototype  ISHMS.  Upon  completion  of  this  process,  the 
thesis  group  would  then  be  able  to  iterate  the  architectures  further  to  include  anything 
that  was  missed  the  first  time  through. 

3.2.1  Requirements  Definition 

The  first  steps  in  creation  of  the  ISHMS  involve  determining  the  requirements  of 
the  system.  This  process  was  largely  accomplished  in  the  previous  thesis.  In  our  case,  in 
order  to  detennine  what  our  requirements  were,  we  needed  to  detennine  what  the  purpose 
of  our  system  would  be.  After  speaking  with  F-15  engineers  at  Robins  AFB,  the  group 
had  a  few  ideas  about  potential  trouble  spots  on  the  F-15.  For  the  purposes  of  this  thesis, 
the  group  chose  an  aft  engine  bulkhead  that  was  cracking  in  the  Jet  Fuel  Starter  Bay. 

This  area  turned  had  a  very  complex  geometry  that  makes  structural  health  monitoring 
difficult,  but  it  was  chosen  since  it  was  easy  to  access,  and  had  environmental 
requirements  that  were  thought  achievable.  The  primary  environmental  driver  for  this 
area  was  the  high  temperatures  experienced  in  the  bay.  Therefore,  the  primary 
requirement  that  needed  to  be  fulfilled  was  a  high  temperature  capability.  It  also  needed 
to  sense  at  certain  rates  and  frequencies  that  were  deemed  acceptable.  Once  these 
attributes  were  chosen,  the  next  step  of  the  process  was  to  select  a  data  collection  device. 
In  this  step,  an  assumption  was  made  that  whatever  sensors  were  chosen  would  need  the 
capability  to  be  hooked  up  to  an  ordinary  laptop  via  USB.  Therefore,  in  this  case,  the 
data  collection  requirements  that  needed  to  be  fulfilled  were  simple.  The  thesis  group 
only  required  a  laptop  with  a  USB  input  and  with  sufficient  storage  and  speed.  Finally, 
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the  group  had  to  determine  the  operational  and  maintenance  requirements.  In  this  step, 
the  group  had  to  determine  what  portions  of  an  actual  aircraft  ISHMS  would  be 
replicated.  We  decided  that  our  setup  would  be  a  simple  aluminum  plate  that  would  be 
damaged.  The  conditions  of  the  laboratory  would  be  similar  to  the  environment  in  an 
aircraft  hanger.  Therefore,  we  would  make  no  attempts  to  reduce  noise  or  temperatures. 
The  tests  would  be  conducted  without  any  special  conditioning.  Essentially,  our 
operational  requirements  boiled  down  to  a  simple  hanger-like  environment.  For 
maintenance  conditions,  we  were  only  truly  concerned  with  the  reliability  of  the  sensors. 
We  did  not  want  a  sensor  that  would  be  prone  to  break  or  malfunction.  This  was 
primarily  to  guard  against  false  test  results.  The  group  did  not  address  other  potential 
maintenance  requirements,  since  the  test  system  was  used  only  in  a  lab  environment. 

After  determining  these  initial  requirements,  the  thesis  group  found  it  necessary  to 
develop  our  vision  for  the  operational  concept. 

The  operational  concept  is  a  step-by  step  walkthrough  of  what  would  be 
accomplished  in  creating  an  ISHMS.  The  first  steps  involve  determining  requirements  by 
working  with  the  users  and  stakeholders.  After  the  requirements  are  defined,  the  system 
would  be  designed  to  meet  the  needs  of  the  specific  structure  being  tested.  After  the 
system  is  designed  and  fabricated,  it  will  be  installed  on  the  aircraft  and  prepared  for 
operational  use.  Once  the  system  is  ready,  operational  usage  will  then  be  accomplished 
as  described  in  the  following  narrative.  After  each  flight,  the  aircraft  will  return  to  the 
hanger  in  normal  fashion.  During  the  normal  post-flight  inspection,  a  maintainer  will  use 
a  laptop  to  connect  to  the  sensors.  The  maintainer  will  begin  by  verifying  that  the 
sensors  are  functioning  properly.  The  maintainer  then  runs  the  test  or  tests  as  detennined 
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during  system  development  and  collects  the  data  from  the  sensors.  Upon  completion  of 
the  test,  the  maintainer  may  disconnect  from  the  sensor  and  continue  to  other  sensors 
until  all  scheduled  inspections  are  complete.  The  tests  will  be  taken  under  nonnal  hanger 
conditions,  so  the  system  must  be  able  to  filter  out  typical  noise.  The  raw  data  from  the 
laptop  is  then  transferred  to  a  central  database  where  engineers  use  software  to  process 
the  data  and  analyze  the  results.  After  data  analysis  is  complete,  the  engineer  directs  a 
course  of  action.  This  course  of  action  may  include  additional  inspections,  flight 
restrictions,  or  maintenance  on  the  aircraft,  the  fleet  or  ISHMS.  This  process  is  then 
repeated  as  necessary  or  upon  completion  of  every  flight.  The  operational  concept  serves 
to  guide  the  thesis  group’s  ultimate  goal  of  creating  a  functional  ISHMS. 

3.2.2  System  Design 

After  the  requirements  were  complete,  the  next  step  in  the  process  was  to  design 
the  system.  The  first  design  step  is  to  choose  sensors.  The  sensor  technology  that  the 
thesis  group  had  chosen  to  use  was  the  METIS  sensor.  This  was  primarily  due  to  the 
technology  being  readily  available  and  from  recommendations  from  other  structural 
health  researchers  including  Maj.  Swenson,  Capt.  Crider,  the  University  of  Dayton,  and 
AFRL/VA  and  AFRU/ML.  After  selecting  the  sensor,  the  group  needed  to  determine 
how  the  sensors  were  going  to  be  used  and  how  many  of  them  we  would  need  to  run  the 
tests.  We  determined  that  we  would  begin  with  a  single  first  generation  sensor  that 
would  enable  us  to  use  the  pulse-echo  method  of  testing.  This  sensor  would  be  attached 
to  a  large  aluminum  sheet.  Damage  would  then  be  simulated  on  the  sheet  until  the  group 
gained  confidence  to  read  the  results.  Next,  actual  damage  would  be  introduced  in  the 
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sheet.  In  addition,  three  second  generation  sensors  would  be  applied  to  the  other  end  of 
the  aluminum  sheet. 

These  sensors  would  be  used  for  the  pitch-catch  method  of  testing.  Again, 
damage  would  be  simulated  between  the  sensors,  eventually  progressing  to  actual 
damage  as  the  technology  is  understood  further.  Now  that  the  thesis  group  had  chosen  a 
sensor  suite,  the  next  step  was  to  design  the  data  collection  device.  Due  to  the 
requirements  imposed  on  the  data  collection  device,  the  group  simply  needed  a  laptop 
with  a  USB  port  and  sufficient  storage  capacity.  Finally,  a  software  package  would  need 
to  be  designed  for  the  system.  One  of  the  benefits  of  choosing  this  specific  sensor  was 
that  the  manufacturer  had  also  developed  a  software  package.  This  software  package  was 
able  to  read  the  data  from  the  sensors  and  display  it  on  the  screen.  It  also  saved  the  data 
in  an  array,  making  it  easy  to  manipulate.  The  only  portion  of  the  software  that  needed  to 
be  designed  further  was  the  analysis  package.  The  software  that  came  with  the  sensors 
had  no  capability  to  input  multiple  signals  from  different  tests  for  comparison.  Capt 
Steve  Crider  had  been  working  with  these  sensors  on  some  different  tests  and  had 
developed  a  Matlab  code  that  would  read  in  data  files  from  a  healthy  and  damaged 
specimen  and  display  them  simultaneously.  It  would  also  display  a  difference  plot  that 
was  useful  in  detennining  where  the  damage  was  located.  His  software  also  allowed  you 
to  input  the  location  on  the  plate  that  was  damaged,  and  it  would  predict  where  the  major 
differences  would  appear.  Through  data  sharing  and  cooperation,  the  thesis  group  was 
able  to  use  his  code  to  generate  test  results  in  exchange  for  the  thesis  group  running 
multiple  tests  for  him  to  use.  The  entire  lab  setup  is  shown  in  figure  3.18 
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Figure  3.18:  Picture  showing  the  laboratory  setup  of  the  test  plate 
3.2.3  System  Installation 

The  final  step  before  being  able  to  test  the  prototype  system  was  to  install  each  of 
the  components.  The  first  item  installed  was  the  sensors.  These  were  attached  with 
standard  two-part  epoxy.  The  epoxy  was  applied  to  the  sensor  and  then  held  firmly  in 
place  on  the  aluminum  until  the  epoxy  cured.  The  software  was  then  installed  on  the 
laptop.  After  software  installation,  the  sensors  could  be  connected  via  USB  to  the  laptop. 
The  thesis  group  then  did  some  initial  testing  in  order  to  become  familiar  with  the 
software.  This  served  as  training  for  the  thesis  group. 


37 


3.2.4  System  Operation 

With  the  ISHMS  system  installed  and  fully  operational,  the  thesis  group  was  able 
to  proceed  with  operation.  To  begin,  the  thesis  group  set  up  the  initial  test  in  the 
laboratory.  Using  the  METIS  software,  the  test  was  initiated.  Upon  completion  of  the 
test,  the  software  notifies  the  user  of  completion.  Meanwhile,  the  data  is  sent  to  the 
computer  for  storage.  The  user  then  requests  the  data  from  the  system,  and  the  computer 
then  displays  the  raw  data.  The  next  step  that  the  thesis  group  took  was  to  compile  the 
data.  In  this  step,  the  test  conditions  were  recorded  along  with  the  raw  data.  The  test 
conditions  included  actuation  frequency,  sample  rate,  number  of  samples,  size  and 
location  of  damage,  and  sensors  used.  In  the  architecture,  the  next  step  is  to  run  mission, 
aircraft,  and  fleet  processing.  Since  the  thesis  group  was  not  using  an  actual  aircraft  to 
run,  the  only  processing  done  at  this  point  was  to  compare  the  data  against  previous 
undamaged  results.  The  next  step  was  to  take  this  filtered  data  and  analyze  it  for 
structural  damage.  The  architecture  attempts  to  capture  all  of  the  various  types  of 
analysis  that  might  be  accomplished  with  an  actual  ISHMS,  however  in  the  thesis  group 
experiment,  various  methods  were  used  for  different  tests.  The  primary  analysis  method 
used  by  the  thesis  group  was  to  plot  a  healthy  result  and  a  damaged  result  on  the  same 
axes  (Figure3. 19).  This  would  allow  the  user  to  see  differences  in  the  frequency  response 
of  the  material.  Additional  plots  were  made  that  showed  the  numerical  differences 
between  two  separate  tests  (Figure  3.20).  Although  the  thesis  group  had  limited  success 
in  conclusively  determining  whether  damage  was  present,  the  concept  proved  promising. 
The  thesis  group  believes  that  many  factors  contributed  to  the  lack  of  definitive  results. 
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Pulse-Echo:  95kHz  Sensor  072 


Figure  3.19:  Healthy  and  Damaged  Plot  on  same  axes 


Figure  3.20:  Difference  between  Healthy  and  Damaged  Plots 
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For  example,  the  thesis  group  believes  that  the  thickness  of  the  plate  deterred  lamb  waves 
from  propagating  through  the  plate  effectively.  Additionally,  different  boundary 
conditions  for  each  test  may  have  played  a  role  in  the  accuracy  of  data.  The  thesis  group 
did  not  attempt  to  control  boundary  conditions  at  a  strict  level,  as  they  attempted  to 
replicate  the  type  of  environment  that  an  aircraft  would  be  tested  in.  Finally,  after 
analyzing  the  results  of  the  testing,  the  thesis  group  was  able  to  make  a  judgment  on 
whether  the  damage  was  detectible  for  each  specific  test.  This  action  constituted  the 
groups’  recommended  action,  although  no  effort  was  made  to  repair  or  categorize  the 
damage,  since  this  test  was  simply  for  concept  demonstration  purposes.  Upon 
completion  of  the  testing,  a  maintenance  action  would  follow  a  test  in  which  damage  was 
discovered.  Apart  from  this  final  step,  the  thesis  group  was  able  to  utilize  the  ISHMS 
architecture  to  set-up  and  operate  a  basic  ISHMS.  Although  the  laboratory  set-up  was 
simplified  greatly,  the  concept  of  an  ISHMS  installed  on  an  aircraft  was  proven 
successfully. 
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IV.  Sensor  Integration 


This  chapter  introduces  demonstrates  the  methodologies  used  to  integrate  the 
METIS  sensors  into  a  functional  ISHMS.  The  group  began  testing  with  the  first- 
generation  “pulse-echo”  sensors,  and  ended  with  the  second  generation  “pitch-catch” 
sensors  in  a  complex  structural  test  setup. 

4.1  Introduction 

One  of  the  primary  considerations  in  defining  and  designing  an  ISHMS  is  the 
selection  and  integration  of  the  various  sensors  that  will  be  used  to  gather  the  data  that  is 
required  in  order  for  the  system  to  function.  Part  of  any  requirements  definition  and 
design  process  involves  assessing  the  available  resources  as  well  as  any  future  “enabling” 
technologies  which  may  provide  increased  capability  to  the  system  under  consideration. 
One  of  the  primary  drivers  in  the  recent  employment  of  ISHMSs  has  been  the 
development  of  new  sensors  with  increased  capability,  not  only  in  terms  of  the 
information  they  can  provide,  but  also  with  respect  to  their  size  and  reliability.  Many 
cutting  edge  technologies  are  currently  being  integrated  into  hardware  packages  that 
enable  their  use  outside  of  a  laboratory  environment.  Some  of  these  new  sensor  packages 
have  been  proven,  while  many  more  are  still  in  a  prototype  phase  of  development. 
Identification  of  these  technologies  initiates  its  own  iteration  of  the  systems  engineering 
process  already  underway,  a  smaller  undertaking  within  the  larger  scope  of  the  ISHMS 
effort.  A  promising  sensor  technology  must  be  assessed  not  only  on  its  viability  for  the 
task  at  hand,  but  must  also  with  respect  to  its  maturity,  availability,  supportability  and 
robustness  to  perfonn  in  the  intended  environment.  In  many  cases,  these  issues  are 
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defined  in  terms  of  overall  risk  to  the  project  vs.  the  potential  payoff  that  the  expected 
data  will  provide  the  user.  As  is  the  case  with  many  cutting  edge  technologies,  a  parallel 
path  will  usually  be  taken  in  the  requirements  definition  and  design  phase  of  the  project 
which  will  allow  for  the  integration  of  the  latest  hardware,  while  at  the  same  time, 
maintaining  a  proven  design  baseline  with  less  capability  as  a  backup.  Often,  separate 
developmental,  or  risk  reduction  efforts  are  undertaken  with  new  technologies  in  parallel 
with  the  development  of  the  overall  system.  Even  though  the  development  effort  of  the 
new  technology  will  follow  a  separate  systems  engineering  process,  the  overall  ISHMS 
effort  is  very  much  dependant  of  the  outcome  of  the  smaller  effort,  which  will  in  turn  be 
driven  by  the  performance,  cost  and  schedule  constraints  of  the  main  process. 

The  systems  engineering  process  undertaken  in  this  thesis  includes  such  an  effort 
as  described  above.  During  the  selection  of  a  real-world  problem  to  act  as  the 
requirements  driver  for  our  system,  an  emerging  sensor  technology  was  identified  with 
the  potential  to  provide  excellent  damage  detection  capability  and  ease  of  operation.  It 
was  decided  that  this  thesis  group  would  undertake  a  parallel  effort  to  detennine  the 
potential  for  integrating  this  technology  into  the  ISHMS,  and  conduct  tests  to  try  and 
establish  the  “real  world”  capability  of  the  prototype  sensor  package. 

4.2  Damage  Detection  using  Lamb  Wave  Propagation 

The  potential  for  using  Lamb  waves  to  detect  damage  in  solid  structures  has  been 
the  focus  of  much  recent  theoretical  research  and  laboratory  experimentation.  Simply 
stated,  a  Lamb  wave  is  a  phenomenon  wherein  a  waveform  of  the  appropriate  shape 
propagates  through  a  solid  material  in  a  uniform  manner.  Because  of  their  shape,  these 
waves  do  not  decay  quickly  as  they  spread  out  through  the  solid  medium.  Since  the  lamb 
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wave  travels  through  the  solid  as  an  elastic  phenomenon,  it  is  affected  by  the  properties 
of  the  material.  When  a  structural  element  is  damaged,  it  experiences  a  dramatic  and 
highly  localized  change  in  material  properties.  A  Lamb  wave  traveling  through  the 
damaged  element  would  be  affected  in  two  ways.  First,  a  physical  change  in  the  material 
such  as  a  crack  or  impact  damage  would  generate  a  reflection,  altering  the  pattern  of 
travel  of  the  wave.  Secondly,  the  localized  change  in  material  properties  would  serve  to 
attenuate  the  wave  as  is  passed  through  the  damaged  area,  affecting  both  the  amplitude 
and  the  frequency  of  the  wave.  The  resulting  theory  is  that  if  a  Lamb  wave  could  be  sent 
out  into  a  solid  material  (such  as  an  aircraft  structural  member)  and  then  be  recorded  as  it 
traveled  through  the  material  then  changes  in  the  material  would  generate  a  different 
“signature”  as  the  Lamb  wave  was  recorded  over  a  period  of  time. 

Many  theoretical  studies  have  been  completed,  verifying  the  existence  of  Lamb 
waves.  Additionally,  much  experimental  work  has  been,  and  continues  to  be 
accomplished  which  validates  the  theory  in  actual  practice.  Typical  experimental  setups 
employ  piezo-ceramic  wafers  as  both  the  actuating  and  sensing  elements.  A  Lamb  wave 
is  generated  from  one  node,  and  is  recorded  at  one  or  more  nodes  according  to  the 
configuration  of  the  test  specimen.  The  capability  of  these  systems  is  highly  dependent 
on  the  structural  element  being  tested,  both  in  terms  of  the  material  properties  and  the 
physical  geometry.  The  material  properties  of  the  specimen  affect  the  maximum  range 
that  the  Lamb  waves  can  travel  and  the  frequency  requirements  for  generating  the  wave. 
The  physical  geometry  of  the  specimen  also  affects  the  range  of  the  waves,  but  may  also 
additionally  restrict  the  possibilities  for  sensor  placement.  As  is  true  in  any  structural 
analysis,  the  more  complex  the  overall  system,  the  more  difficult  it  is  to  properly  identify 
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the  optimal  wave  shape,  frequency  and  sensor  location.  Recently,  there  have  been  efforts 
made  to  package  this  technology  into  a  sensor  package  for  use  in  real-world  situations. 

4.3  METIS  Sensor  Package 

One  such  sensor  package  is  produced  by  the  Metis  Design  Corporation  (MDC) 
and  has  been  procured  in  limited  quantities  by  AFRL  and  AFIT  for  the  purpose  of  further 
exploration  into  their  potential.  The  METIS  sensor  is  a  self  contained  package  that  uses 
piezoelectric  wafers  to  send  and  receive  Lamb  waves  through  the  structural  element  to 
which  it  is  bonded.  All  the  necessary  components  for  controlling  the  sensor  are  built  into 
the  disk  which  is  housed  in  a  3cm  diameter  by  1cm  thick  enclosure.  The  sensors  received 
for  this  evaluation  are  powered  and  controlled  through  a  standard  USB  cable,  although 
wireless  models  powered  by  a  thin- film  Lithium  polymer  battery  are  also  in  development. 
The  sensor  is  controlled  through  a  provided  software  interface  which  allows  the  user  to 
perform  tests  at  any  frequency,  amplitude,  or  wave  form  desired  within  the  capacity  of 
the  sensor.  The  software  also  allows  the  user  to  collect  data  using  the  average  value  of 
multiple  consecutive  data  runs  which  can  be  selected  via  the  user  interface.  The  METIS 
sensor  can  be  operated  in  two  distinct  modes;  Pulse-Echo,  and  Pitch-Catch.  In  Pulse- 
Echo  mode,  a  single  sensor  sends  out  the  predefined  signal  (Pulse)  from  the  actuating 
disk,  and  records  the  resulting  signal  (Echo)  through  the  receiving  disk  from  the 
structural  element.  In  Pitch-Catch  mode,  a  pair  of  sensors  is  utilized,  with  the  first  sensor 
sending  out  the  signal  (Pitch)  from  its  actuating  disk  with  a  second  sensor  recording 
(Catch)  the  signal  through  its  receiving  disk.  In  Pitch-Catch  mode,  the  actuating  sensor  is 
also  recording  data  through  its  receiving  disk,  in  essence  acting  as  a  Pulse-Echo  sensor  as 
well. 
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4.4  Test  Methodology 

As  mentioned  above,  previous  testing  with  the  METIS  sensor  had  verified  the 
ability  of  the  system  to  detect  damage  in  a  simplified  structural  element.  The  primary 
objective  of  this  thesis  group  was  to  detennine  if  the  METIS  sensor  could  function  in  a 
more  realistic,  i.e.  more  structurally  complex  environment.  As  described  previously,  the 
design  driver  for  our  ISHMS  was  the  F-15  bulkhead  crack  discovered  on  a  single 
operational  aircraft  and  currently  being  studied.  A  secondary  objective  of  this 
experiment  was  to  try  and  determine  just  how  sensitive  the  sensor  was  with  respect  to  the 
size  of  the  damaged  area.  Along  the  way  the  group  would  also  be  evaluating  the  software 
interface,  and  trying  to  establish  any  undesired  correlation  between  our  test  methodology 
and  the  data  produced.  Initial  discussions  centered  on  the  actual  structural  element  that 
would  serve  as  the  platform  for  our  testing.  Several  designs  were  produced  with 
simplified  versions  of  the  bulkhead  flange,  shear  web,  and  longeron  attach  joints. 
Producing  a  specimen  that  could  be  placed  in  a  test  cell  and  subjected  to  cyclic  loading 
was  briefly  considered,  but  ultimately  not  pursued  since  it  provided  no  direct  benefit 
towards  answering  the  main  question  of  sensor  capability.  During  this  time  frame  a 
section  of  an  actual  F-15  bulkhead  was  requisitioned  from  the  Aerospace  Maintenance 
and  Regeneration  Center  at  Davis-Monthan  Air  Force  Base.  This  bulkhead  is  shown  in 
Figure  4.1 
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Figure  4.1:  F-15  Bulkhead  Section 


After  the  bulkhead  section  arrived  at  the  lab  it  became  apparent  that  the  group 
would  be  unable  to  re-create  the  complexity  of  the  structure.  It  had  also  become  clear 
that  no  work  had  been  done  with  these  types  of  sensors  in  complex  structural 
environments.  All  of  the  published  work  that  could  be  located  had  been  accomplished  on 
flat  plates  in  controlled  environments.  This  included  work  currently  being  done  at  AFIT 
by  Capt.  Steve  Crider,  whose  research  would  serve  as  a  starting  point  for  our  own  efforts. 
The  thesis  group  ultimately  decided  to  begin  our  experiments  as  in  all  previous  cases, 
with  a  flat  plate.  The  goal,  however,  would  be  to  progress  to  a  more  structurally  complex 
system  while  verifying  the  capability  of  the  METIS  sensor. 

All  testing  was  conducted  using  a  large  rectangular  plate  of  7075-0  aluminum 
measuring  21  ”x42”xl/4”.  During  testing,  the  plate  was  supported  by  six  small  wooden 
blocks  underneath  each  corner  and  at  the  middle  of  each  of  the  long  edges,  in  an  attempt 
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to  isolate  the  plate  from  any  vibrations  coming  from  the  building,  floor,  or  desk,  and  to 


allow  for  a  more  unconstrained  response  from  the  plate  (Figure  4.2). 


Figure  4.2:  General  setup  of  Test  Plate 


The  plate  of  course  was  not  perfectly  isolated  from  vibration,  nor  was  it  removed 
at  all  from  any  ambient  noise,  but  this  was  considered  to  be  acceptable  in  two  ways. 

First,  all  of  the  test  results  generated  were  with  respect  to  the  baseline  state  of  the  plate 
itself,  so  as  long  as  the  test  setup  was  consistent  and  repeatable,  the  results  should  be  free 
from  major  deviations.  Secondly,  the  main  objective  of  this  series  of  tests  was  to 
establish  the  viability  of  this  sensor  package  for  real  world  use,  and  attempting  to 
establish  a  laboratory  like  environment  would  defeat  this  ultimate  goal.  The  second  main 
objective  of  this  test  was  to  try  and  estimate  the  threshold  damage  size  that  could  be 
detected  with  this  system,  which  required  at  least  some  level  of  background  noise  to 
correlate  with.  Ultimately  the  question  of  background  noise  and  sufficient  baseline  data 
would  become  major  issues  during  interpretation  of  the  actual  test  data. 
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Based  on  our  knowledge  of  testing  that  had  been  accomplished  or  was  currently 
ongoing,  and  our  own  goal  of  testing  a  more  structurally  complex  system,  the  group 
devised  our  initial  test  matrix.  The  test  progression  would  allow  us  to  start  in  an  area  that 
was  similar  to  Capt  Crider’s  work,  allowing  the  group  the  chance  to  verify  our  methods 
and  results  in  comparison  to  his  before  moving  into  unknown  territory.  The  original  test 
matrix  is  shown  in  figure  4.3. 


1.  Baseline  Plate 

6. 

Actual  Damage  -  Outside 
Reflection  Boundary 

2.  Single  Block  -  Inside 

1.  Scratch  -  Looking  for 

Reflection  Boundary 

Minimum  Detectable  Change 

a.  Different  Orientations 

m.  Gouge  -  Vary  Size  Based  on 

b.  Different  Sizes 

Previous  Results 

c.  Different  Shapes 

n.  Punch  -  Simulate  Impact 

Damage 

3.  Multiple  Blocks  -  Inside 

i.  Different  Orientations 

Reflection  Boundary 

ii.  Different  Locations 

d.  Variable  Spacing 

iii.  Different  Radial 

e.  Stacked  -  Same  Radial 

Distances 

Line 

iv.  Stacked  -  Same  Radial 

Line 

4 .  Single  Block  -  On 

Reflection  Boundary 

v.  Equal  Radial  Distance 

f.  Different  Orientations 

7  . 

Building  Up  Complexity  of  the 

g.  Different  Sizes 

Plate 

h.  Different  Shapes 

o.  Drill  out  Damages  Areas  in 
Stacked  Series 

5.  Single  Block  -  Outside 

p.  Add  Bolts/Stiffeners  to 

Reflection  Boundary 

Plate  Parallel  to  Wave  Path 

i.  Different  Orientations 

q.  Drill  out  Damaged  Areas  to 

j  .  Different  Sizes 

Allow  for  Perpendicular 

k.  Different  Shapes 

Stiffeners 

r.  Add  Bolts/Stiffeners  to 

Plate  Perpendicular  to  Wave 
Path 

8. 

Add  Actual  Damage  to  Bolt  Holes 
Under  Stiffeners  (Simulate 

Crack  Initiation) 

Figure  4.3:  Initial  Pulse-Echo  Test  Matrix 
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As  can  be  seen  from  the  initial  test  matrix,  a  large  amount  of  data  was  to  be 
collected  using  the  “simulated”  damage  method  employed  by  Capt.  Crider  and  others. 
Simulating  damage  to  the  plate  offered  several  advantages,  the  most  obvious  of  which 
was  that  the  plate  was  not  actually  damaged  and  could  be  measured  in  its  baseline  state  at 
the  start  of  each  test  session.  Another  advantage  was  that  many  different  combinations  of 
damage  could  be  explored,  including  the  size,  shape,  and  orientation  of  the  damaged  area, 
as  well  as  any  possible  combination  of  damage  types.  A  final  and  not  insignificant 
advantage  to  simulated  damage  was  that  it  allowed  for  operator  training  and 
familiarization  with  both  the  sensors  capabilities  and  the  software  interface.  For  the 
purpose  of  damage  detection  using  Lamb  waves,  simulating  the  damage  condition  can  be 
accomplished  in  several  ways.  The  basic  principal  is  to  create  a  highly  localized  change 
in  the  properties  of  the  material,  most  notably,  stiffness.  This  can  be  accomplished  by  the 
use  of  a  clamp  or  vise,  or  even  through  the  application  of  heat,  but  each  of  these  methods 
carries  a  risk  of  pennanently  altering  the  plate.  For  our  purposes,  small  aluminum  or 
steel  blocks  (see  figure  4.4)  were  placed  on  the  surface  of  the  test  plate,  using  shear 
coupling  gel  to  “attach”  the  two  pieces.  The  addition  of  the  block  produces  a  localized 
change  in  stiffness  of  the  plate  which  mimics  an  area  of  actual  damage.  The  shear 
coupling  gel  allows  the  Lamb  waves  propagating  through  the  structure  to  interact  more 
effectively  with  the  block,  producing  the  best  possible  results  in  the  data  collected. 
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Figure  4.4:  Blocks  used  for  Simulated  Damage  Testing 


An  initial  test  period  allowed  the  group  time  to  learn  the  software  interface,  and 


collect  data  that  we  could  correlate  with  the  results  produced  by  Capt.  Crider.  It  also 


allowed  the  group  to  verify  that  the  sensor  was  installed  and  operating  correctly.  During 


the  initial  learning  curve  we  also  explored  the  range  of  frequencies  that  the  sensor  was 


capable  of  outputting.  Capt.  Crider  had  identified  95  kHz  as  the  optimum  frequency  for 


the  plate  he  was  testing,  and  our  initial  trials  verified  this  was  also  the  case  for  our  plate. 


Since  the  group  had  long  range  plans  to  significantly  alter  the  structural  state  of  our  test 


specimen,  we  decided  to  continue  testing  over  a  fairly  large  frequency  range,  ultimately 


utilizing  a  live  frequency  spread  from  35  to  155  kHz.  During  this  initial  period  the  group 


also  evaluated  the  software’s  averaging  function.  Taking  multiple  sets  of  data  from  the 


clean  plate,  using  the  various  averaging  settings,  we  compared  the  results  and  selected 


the  lowest  averaging  setting  (128  run  average)  above  which  a  difference  could  no  longer 


be  discerned  in  the  resulting  data  plots.  One  area  the  group  did  not  explore  during  our 


testing  was  the  actual  waveform  that  the  sensor  generated.  The  software  interface 
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allowed  for  changes  to  be  made  to  the  Lamb  wave  fonn  produced  by  the  sensor.  Based 
on  Capt.  Crider’s  results,  the  default  wave  form  was  very  effective  for  our  basic  plate, 
and  felt  that  it  would  remain  so  as  the  structural  complexity  of  the  specimen  was 
increased. 

Once  the  initial  learning  curve  was  complete,  a  series  of  tests  using  blocks  of 
various,  size,  shape  and  weight  was  conducted  in  an  attempt  to  characterize  the  capability 
of  the  sensor  with  respect  to  the  location,  relative  size  and  orientation  of  the  “simulated” 
damage.  Additionally,  tests  were  conducted  using  multiple  blocks  in  order  to  evaluate 
the  ability  of  the  sensor  to  provide  distinct  returns  for  more  than  one  damaged  area. 

After  completing  “simulated”  damage  testing,  we  proceeded  to  actually  damaging  the 
plate.  There  was  obviously  less  flexibility  when  it  came  to  actual  damage,  but  the  basic 
plan  was  to  try  and  start  with  the  smallest  damage  possible,  and  then  to  work  up  in  size, 
with  some  changes  in  orientation  and  location  to  see  how  the  results  varied.  The  plan  for 
actual  damage  included  several  locations  which  would  eventually  be  drilled  out,  and 
were  spaced  to  allow  for  the  future  addition  of  other  structural  members  to  the  plate.  This 
would  be  done  in  an  attempt  to  build  up  the  complexity  of  the  overall  structural  element 
and  increase  the  density  of  the  baseline  signal  from  which  an  area  of  new  damage  would 
have  to  be  detected. 

Initial  testing  was  conducted  using  a  first  generation  Pulse-Echo  sensor  which 
allowed  us  to  mimic  testing  already  accomplished  by  Capt.  Crider.  Subsequent  testing 
was  accomplished  using  second  generation  Pitch-Catch  sensors,  which  are  also  capable 
of  Pulse-Echo  operation.  The  software  interface  required  to  operate  these  sensors  was 
provided  by  the  METIS  Corporation,  and  can  best  be  described  as  an  “in  house”  or 
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“prototype”  system,  being  used  by  the  company  to  develop  the  sensor  package  and  define 
the  user  interface.  The  programs  produced  data  files  in  either  Excel  or  Comma  Separated 
Value  (.csv)  format  depending  on  if  the  “demo”  or  “test”  version  of  the  software  was 
being  utilized.  Data  reduction  was  accomplished  in  both  Matlab,  and  Excel.  For 
“simulated”  damage  testing,  a  baseline  data  set  was  recorded  at  the  start  of  each  day.  For 
actual  damage  testing,  a  minimum  of  2  baseline  data  sets  were  recorded  between  each 
successive  damage  addition,  with  3  sets  of  data  being  the  nonnal  process.  Digital 
photographs  were  taken  to  record  the  simulated  or  actual  damage  condition  of  each  test 
run.  Pre  and  post  test  pictures  were  taken  of  the  simulated  damage  test  setup  to  document 
the  condition  of  the  shear  gel  contact  area  under  each  block. 

4.5  Test  Results:  First  Generation  METIS  Sensor 

Initial  testing  was  accomplished  using  one  of  the  first  generation  Pulse-Echo  type 
sensors  which  was  already  being  utilized  in  other  experiments  and  was  immediately 
available.  These  “first-generation”  sensors  are  only  capable  of  Pulse-Echo  operations 
and  are  somewhat  limited  in  their  output  capability.  The  advertised  output  for  the 
standard  METIS  sensor  is  20  volts  peak  to  peak,  while  the  sensors  being  used  at  AFIT 
had  only  a  6  volt  peak  to  peak  capacity.  This  limitation  was  not  expected  to  be  an  issue 
since  the  sensors  were  already  in  use  and  seemed  to  be  performing  fine.  The  large  plate 
was  exactly  rectangular  in  shape.  The  long  edge  was  exactly  twice  as  long  as  the  short 
edge,  essentially  creating  two  square  surfaces.  The  sensor  was  applied  to  the  center  of 
one  of  the  square  ends  of  the  plate  such  that  the  sensor  was  equal-distance  from  3  edges 
of  the  plate  (see  figure  4.5).  This  created  a  situation  approximately  equivalent  to  the 
large  square  plate  being  tested  by  Capt.  Crider.  Previous  experience  had  shown  that  any 
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discontinuity  in  the  plate,  especially  the  edges,  would  produce  strong  reflections  of  the 
Lamb  wave  back  to  the  sensor.  On  the  square  plate,  these  returns  would  all  reach  the 
sensor  at  the  same  time,  producing  a  very  predictable  and  regular  data  pattern  that  helped 
in  analyzing  subsequent  information.  In  addition,  the  symmetric  shape  of  the  square 
plate  actually  caused  a  reduction  in  the  number  of  reflections  since  any  wave  that  didn’t 
hit  the  edge  of  the  plate  perpendicularly  was  met  by  a  similar  reflection  from  an  adjacent 
plate  edge,  and  cancelled  out.  Although  not  as  efficient  as  the  purely  square  plate,  the 
rectangular  plate  produced  the  same  type  of  distinct  reflection  pattern.  As  mentioned 
previously,  damage,  or  more  precisely,  a  change  in  the  material  property  of  the  plate, 
produced  two  unique  phenomenon  that  were  observed  in  the  sensor  data.  The  first  was  a 
reflection  of  the  lamb  wave  off  of  the  damaged  area,  which  shows  up  in  the  data  plot  as 
change  outside  of  the  normal  reflection  pattern.  The  second  change  was  caused  by  an 
absorption  of  energy  from  the  Lamb  wave  as  it  passed  by  the  damaged  area  twice,  once 
as  the  wave  passed  the  site  outbound  from  the  sensor,  and  once  again  on  the  way  back  to 
the  sensor  after  being  reflected  from  the  edge  of  the  plate.  This  effect  was  observed  as 
both  a  change  in  amplitude  in  the  normal  reflection  pattern,  and  as  a  shift  in  the  timing  of 
the  reflection  pattern,  due  to  the  attenuation  of  the  frequency  of  the  original  signal.  Of 
these  two  effects,  the  change  in  amplitude  appeared  to  be  more  noticeable,  possibly  due 
to  the  relative  size  of  the  damage  with  respect  to  the  rest  of  the  plate.  These  phenomenon 
obviously  continued  to  occur  as  the  wave  bounced  back  and  forth  multiple  times  from  the 
edges  of  the  plate  and  past  the  sensor,  but  we  had  concentrated  our  analysis  to  the 
primary  reflection  from  the  damaged  area,  and  the  primary  reflection  from  the  three 
closest  edges.  These  reflections  were  the  strongest  and  cleanest  returns.  For  the 
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purposes  of  testing,  the  plate  was  divided  into  two  areas,  separated  by  what  is  referred  to 
as  the  “reflection  boundary”  (see  figure  4.5).  This  boundary  was  defined  by  a  circle, 
centered  on  the  sensor  that  extends  to  the  3  nearest  edges  of  the  plate. 


Figure  4.5:  Large  Plate  with  First  Generation  Sensor  Installed 
Damage  that  occurs  inside  the  reflection  boundary  will  produce  a  reflection  that 
should  be  observed  before  the  first  primary  edge  returns,  and  should  produce  attenuation 
effects  within  the  primary  edge  return.  Damage  outside  the  reflection  boundary  should 
have  no  observable  effect  on  the  primary  edge  returns  (or  the  secondary  edge  returns 
depending  on  the  location  of  the  damage).  This  result  was  important  because  it  gave  us  a 
clue  as  to  whether  damage  could  be  identified  in  a  return  signal  from  a  more  complicated 
structure,  with  multiple  sources  of  reflections  and  interference.  The  final  case  occurs 
when  the  damage  lies  on  the  reflection  boundary  (or  some  whole  number  multiple  of  the 
reflection  boundary  distance)  which  will  only  generate  a  change  in  the  edge  returns.  The 
group’s  initial  test  runs  involved  taking  multiple  sets  of  baseline  data  with  the  clean  plate, 
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with  several  objectives.  The  first  task  was  to  compare  the  different  baseline  results  in 
order  to  establish  the  level  of  “background”  noise  that  we  could  expect  from  run  to  run. 
This  result  was  especially  important  since  the  primary  mechanism  for  damage  detection 
using  the  METIS  sensor  is  the  continuous  comparison  of  data  with  previously  existing 
baselines.  The  effectiveness  of  the  sensor  was  dependent  on  the  groups’  ability  to 
separate  the  “damage”  return  from  the  “noise”  inherent  to  the  system.  Our  analysis  of  the 
initial  simulated  damage  tests  were  accomplished  using  a  program  written  by  Capt. 

Crider.  This  data  reduction  program  not  only  plotted  the  sensor  data,  but  also  calculated 
the  expected  locations  for  primary  edge  reflections  and  secondary  reflections  generated 
by  the  damaged  area.  This  was  accomplished  by  inputting  the  exact  dimensions  and 
material  properties  of  the  plate,  the  location  of  the  damaged  area  and  the  frequency  of  the 
Lamb  wave.  The  initial  results  using  this  program  were  not  encouraging.  The  locations 
of  the  expected  returns  did  not  coincide  with  the  predictions  generated  by  the  program, 
and  the  magnitude  of  the  returns  produced  by  the  damage  were  significantly  less  than 
expected  based  on  Capt.  Crider’s  test  data.  Even  though  we  continued  to  progress 
through  the  test  matrix  we  spent  a  great  deal  of  time  trying  to  explain  the  unexpected 
results  we  were  seeing.  Eventually  we  suspended  testing  and  tried  to  focus  on 
understanding  the  results.  The  groups’  initial  assessment  of  the  situation  was  that  the 
physical  size  and/or  shape  of  the  plate  was  affecting  the  results.  The  plate  we  were  using 
was  substantially  larger  than  the  one  used  by  Capt.  Crider,  possibly  masking  the  returns 
produced  by  the  small  aluminum  blocks  being  used  to  simulate  damage.  The  second  area 
of  concern  had  to  do  with  the  shape  of  the  plate.  It  became  apparent  that  the  plate  was 
not  perfectly  flat,  and  would  actually  sag  along  its  long  axis  when  sitting  on  the  wooden 
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blocks.  This  effect  was  first  seen  in  some  of  the  post-test  pictures  taken  of  the  damage 
blocks  after  they  had  been  removed  (see  figure  4.6). 


Figure  4.6:  Post-Test  Pictures  Showing  Partial  Contact  of  Damage  Blocks 


The  pattern  of  the  shear  gel  on  the  plate  gave  the  group  a  clear  indication  that  the 
blocks  were  not  making  uniform  contact  with  the  plate,  especially  when  they  were  placed 
along  the  center  axis  of  the  plate.  After  considering  the  problem,  the  group  decided  to 
address  the  problem  by  modifying  the  damage  position.  To  address  the  contact  issue,  the 
group  conducted  a  series  of  tests  at  different  locations  and  orientations  on  the  plate  to 
minimize  the  effects  of  the  sagging  plate.  In  addition,  a  selection  of  steel  blocks  was 
obtained  in  order  to  increase  the  magnitude  of  the  simulated  damage  by  simply  increasing 
the  magnitude  of  the  local  change  in  stiffness  of  the  plate.  Although  both  of  these 
changes  produced  the  desired  effects,  the  data  plots  generated  using  Capt.  Crider’s 
program  did  not  show  any  significant  improvement.  At  this  point,  the  group  had  been 
resigned  to  the  possibility  that  the  first  generation  sensor  simply  did  not  have  enough 
output  capability  to  “see”  damage  in  this  large  plate.  The  next  step  was  to  begin  actually 
damaging  the  plate.  Due  to  the  groups’  suspicions  that  the  sensor  might  lack  the  output 
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necessary  for  this  plate,  the  group  elected  to  move  our  first  damage  location  inside  the 
reflection  boundary  in  order  to  increase  the  chances  of  success.  A  total  of  four 
successively  larger  areas  of  damage  were  produced  at  the  same  location  on  the  plate  (see 
figure  4.7).  Initial  reviews  of  the  data  showed  that  the  actual  damage  produced  an  even 
smaller  return  than  the  simulated  damage  blocks.  In  many  cases,  the  group  was  unable  to 
determine  that  any  change  had  taken  place  to  the  plate  at  all.  At  this  point  the  group  was 
convinced  that  the  sensor  simply  was  not  capable  of  producing  a  strong  enough  wave  to 
illuminate  the  damage  in  the  plate.  More  precisely,  the  changes  in  the  wave  produced  by 
the  damage  in  the  plate  were  so  small,  relative  to  the  original  size  of  the  wave,  that  we 
were  unable  to  distinguish  them  from  the  background  noise  coming  through  the  sensor. 
This  had  always  been  one  of  the  biggest  unknowns  with  regards  to  the  usefulness  of  this 
sensor  technology  in  an  operational  environment  where  background  noise  is  a  fact  of  life. 
To  present  both  sides  of  the  story,  it  must  be  noted  that  we  made  no  attempt  to  control  the 
background  noise,  nor  did  we  make  any  attempt  to  try  and  filter  the  data  to  account  for 
background  noise.  There  are  in  fact,  many  methods  in  use  which  can  effectively  filter 
sensor  data  and  highlight  specific  data  ranges  for  analysis.  Our  overarching  concept, 
however,  was  to  maintain  the  simplest  methods  possible,  and  the  highest  level  of  data 
presentation  in  an  attempt  to  establish  the  absolute  capability  of  the  sensor  package. 
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Figure  4.7:  Actual  Damage  for  initial  Pulse-Echo  Sensor  Testing 
At  this  point  in  the  process  the  group  had  concluded  that  the  first  generation  sensor  was 
not  capable  enough  for  the  task  at  hand,  and  that  we  would  need  to  wait  for  the  second 
generation  sensors  which  had  been  ordered  from  MDC.  While  the  group  waited  for  the 
next  batch  of  sensors  to  arrive  we  began  to  experiment  with  a  different  data  reduction 
process,  utilizing  simple  spreadsheet  calculations  and  plotting.  Much  to  our  surprise  we 
came  up  with  much  different  results  for  the  simulated  damage  testing  then  we  had  been 


58 


seeing  with  Capt.  Crider’s  Matlab  program.  For  the  most  part,  the  simulated  damage 
tests  were  almost  universally  positive,  meaning  that  we  could  see  an  obvious  change  to 
the  plate  in  every  case,  and  usually  at  every  frequency.  This  change  in  results  did  not, 
however,  extend  to  the  actual  damage  cases,  which  still  showed  no  clear  indications  of 
damage  in  the  data.  A  summary  table  of  the  test  results  is  presented  in  figure  4.8. 


Pulse  Echo  Test  Results:  Sensor  0072 
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Figure  4.8:  Sensor  0072  Pulse-Echo  Test  Results 
These  new  results  forced  the  group  to  reconsider  some  of  the  conclusions  we  had 

made  up  to  this  point,  and  also  provided  some  new  infonnation  with  respect  to  the 
methods  being  used.  The  first,  most  obvious  conclusion  was  that  we  had  somehow 
misused  the  software  created  by  Capt.  Crider  in  the  processing  of  our  data.  After  some 
consideration  it  was  concluded  that  we  had  not  provided  accurate  enough  information 
with  respect  to  the  dimensions  and  material  properties  of  our  test  plate  to  allow  the 
program  to  function  properly.  This  conclusion  only  explained  why  the  predictive  models 
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in  the  program  were  inaccurate,  and  did  not  account  for  the  reduction  in  magnitude  seen 
between  our  data  and  Capt.  Crider’s.  After  comparing  the  results  from  the  two  different 
data  processing  routines  we  determined  that  the  magnitude  of  the  results  was  consistent, 
and  that  our  original  assumption  that  the  plate  was  simply  too  large  for  the  output  of  the 
sensor  was  accurate.  The  next  conclusion  we  drew  from  the  test  results  was  that  our 
simulated  damage  testing  was  not  a  good  indicator  of  sensor  performance  with  respect  to 
actual  damage  detection.  The  signature  produced  by  the  blocks  was  obviously  different 
in  terms  of  magnitude  and  definition  compared  to  the  actual  damage.  This  is  not  to  say 
that  simulated  damage  testing  was  not  useful,  only  that  the  method  we  used  did  not 
produce  results  that  were  comparable  to  actual  damage.  The  final  conclusion  that  we 
made  was  actually  an  affirmation  of  one  of  our  earlier  results.  The  first  generation 
METIS  sensor  does  not  have  that  capacity  to  detect  damage  in  the  plate  we  were  testing. 
Even  as  we  increased  the  size  of  the  damaged  area,  the  sensor  returns  did  not  pick  up  the 
change.  It  is  entirely  possible  that  this  sensor  could  be  used  in  a  different  location,  on  a 
smaller  specimen,  but  it  was  insufficient  for  our  test  setup. 

4.6  Test  Results:  Second  Generation  METIS  Sensor 

The  second  generation  METIS  sensors  are  outwardly  no  different  from  the  first 
generation  models.  The  difference  between  the  two  stems  from  the  fact  that  the  second 
generation  model  can  operate  in  either  Pitch-Catch  or  Pulse  Echo  mode,  and  is  capable  of 
its  full  advertised  output  of  20  volts  peak  to  peak.  The  group’s  first  batch  of  new  sensors 
was  delayed  after  MDC  discovered  a  flaw  in  the  first  batch  produced.  While  waiting  for 
the  sensors  to  arrive  we  contemplated  both  our  planned  test  matrix  and  the  sensor 
placement  we  would  use.  After  considering  several  options  for  testing,  including  a  new 
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plate,  we  chose  to  continue  testing  with  our  original  plate,  adding  a  total  of  three  new 
sensors  equally  spaced  as  shown  in  figure  4.9.  The  location  of  the  new  sensors  was 
chosen  for  two  primary  reasons. 
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Figure  4.9:  Large  Plate  with  All  Sensors  Installed 
First,  using  the  same  plate  allowed  for  potential  comparison  of  both  the  first  and  second 
generation  of  sensors  using  the  same  damage  conditions.  While  this  was  in  fact  never 
accomplished,  the  potential  was  seen  as  a  benefit  towards  using  the  same  plate. 

Secondly,  the  symmetric,  in-line  arrangement  of  the  three  sensors  was  conceived  to  allow 
for  a  “back-up”  arrangement  in  case  of  some  unexpected  results.  The  path  between  the 
center  sensor  and  the  two  outside  sensors  was  essentially  identical.  Even  though  the 
orientation  of  the  outside  sensors  with  respect  to  the  edges  of  the  plate  was  different,  the 
initial  pulse  received  by  the  outside  sensors  was  identical.  Previous  research  had  shown 
that  with  this  arrangement,  baseline  data  between  one  set  of  sensors  can  in  fact  be 
substituted  for  another  with  no  change  in  results.  Our  reasoning  behind  this  arrangement 
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had  more  to  do  with  the  potential  for  damaging  the  plate  in  such  a  way  that  we  could  not 
continue  testing  and  needing  a  second  location  to  continue.  Once  again,  we  never  in  fact 
needed  the  secondary  test  area,  but  the  potential  benefit  influenced  our  final  decision  on 
sensor  location. 

Our  primary  test  location  was  between  sensors  005  and  004.  Most  tests  were 
conducted  using  sensor  005  as  the  actuator  and  sensor  004  as  the  recorder.  The  software 
interface  provided  with  the  sensors  only  supported  two  sensors  during  any  given  test. 

This  turns  out  to  a  fairly  significant  limitation  to  the  overall  concept  of  operations  since 
there  are  many  scenarios  where  the  same  signal  recorded  at  multiple  sensor  locations  can 
provide  infonnation  with  respect  to  the  location  of  the  damaged  area.  Another  operating 
constraint  to  the  software  interface  was  the  speed  at  which  the  tests  were  conducted.  The 
software  could  be  set  up  to  run  a  sweep  of  all  the  selected  frequencies.  Using  the  128 
average  setting  that  we  had  selected,  one  run  would  take  approximately  one  hour  to 
complete.  The  simple  fact  of  not  having  enough  time  available  to  complete  multiple  runs 
kept  us  from  taking  any  significant  amount  of  data  using  sensor  004  as  the  actuator,  and 
prevented  us  from  using  sensor  006  at  all.  Based  on  the  results  of  earlier  testing  we 
modified  our  test  matrix  for  Pitch-Catch  (see  figure  4.10). 

The  group’s  plan  was  to  conduct  minimal  simulated  damage  testing  in  order  to 
verify  that  the  sensors  were  installed  and  functioning  properly.  This  would  also  give  the 
group  enough  experience  with  the  software  interface  to  conduct  further  testing.  Damage 
to  the  plate  was  initiated  at  the  center  point  between  sensors  004  and  005. 
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1.  Baseline  Plate 

2.  Single  Block  -  Between  Sensors 

a.  Different  Sizes/Weights 

b.  Offset  from  Direct  Line 

3.  Actual  Damage  -  On  a  Perpendicular  Line  Between  the 
Sensors 

a.  Gouge  -  Looking  for  Minimum  Detectable  Damage  -  Vary 
Size  Based  on  Previous  Results 

b.  Punch  -  Simulate  Impact  Damage 

c.  Hole  -  Drill  out  Damaged  Areas  using  increasingly 
larger  bits 

4.  Building  Up  Complexity  of  the  Plate 

a.  Drill  out  Damages  Areas  in  Stacked  Series 

b.  Add  Stiffener  to  Plate  Between  Sensors 

5.  Actual  Damage  -  Plate  with  Stiffener 

a.  Damage  Plate  Away  from  Stiffener 

b.  Damage  Plate  Under  Stiffener  -  Simulate  Crack 
Initiating  at  Bolt  Hole 


Figure  4.10:  Initial  Pitch-Catch  Test  Matrix 

Subsequent  damage  was  added  to  the  plate  at  two  locations  offset  from  the  line  between 
sensors  004  and  005.  The  resulting  damage  locations  fonned  a  line  perpendicular  to  the 
line  intersecting  sensors  004  and  005.  Several  types  of  damage  were  added  to  the  plate. 
A  chisel  was  used  to  gouge  the  surface  of  the  plate,  providing  the  closest  analogy  to  a 
crack  that  we  had  the  means  to  inflict.  Impact  damage  was  also  simulated  by  means  of  a 
punch  (Figure  4.11).  Finally,  the  damaged  areas  were  drilled  out  using  a  1/16”  drill  bit, 
followed  by  a  1/4”  drill  bit.  Once  these  three  locations  were  drilled  out,  a  stiffener  was 
added  to  the  plate  to  increase  the  structural  complexity  of  the  system. 
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Damage  3:  3mm  Gouge 


Damage  1 1 :  Impact  (Punch) 


Figure  4.11:  Damaged  Areas 


At  this  point,  additional  damage  was  added  to  the  plate  between  the  stiffener  and  sensor 


005,  and  under  the  stiffener,  originating  from  the  center  hole  location.  This  final 
configuration  would  provide  the  answer  to  the  question  of  whether  or  not  the  sensors  had 


the  capability  to  detect  damage  in  a  more  structurally  complex  environment  (see  figure 


4.12). 


jk 

Plate  w/  Stiffener  Installed 

Damage  14:  Cut  from  Center  Hole 

Figure  4.12:  Damage  Testing  w/  Stiffener  Installed 


A  summary  of  Pitch-Catch  test  results  is  presented  in  figure  4.13.  Results  for  the  limited 
simulated  damage  testing  all  showed  favorable  results,  much  like  the  first  generation 
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Pulse-Echo  sensor.  Actual  damage  testing  showed  generally  better  results  with  the  new 


sensor,  but  the  results  were  inconsistent.  Not  all  damage  types  were  clearly  indicated  in 
the  data,  nor  was  there  any  clear  preference  with  respect  to  the  frequency.  One  surprising 
result  occurred  with  the  stiffener  installed.  In  almost  every  case,  the  damaged  area  was 
clearly  detected  by  the  sensor  when  the  stiffener  was  in  place.  This  led  to  an  obvious 
conclusion  that  the  overall  effectiveness  of  the  sensor  system  is  dependent  on  the 
properties  of  the  system  as  a  whole.  Common  sense  tends  to  support  this  conclusion,  but 
the  results  provided  a  dramatic  illustration  of  this  effect. 


65 


□  Damage  IndicatecO  No  Determination  Possible  H  No  Damage  Indicated 


Figure  4.13:  Pitch-Catch  Test  Results 
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4.7  Conclusions 


Although  somewhat  limited  in  scope  the  testing  completed  by  this  thesis  group 
does  allow  for  several  important  conclusions  with  respect  to  damage  detection  using 
Lamb  wave  technology,  and  the  METIS  sensor  package  in  particular.  The  first  and  most 
obvious  conclusion  is  that  there  is  potential  for  this  technology  and  for  the  METIS  sensor 
to  be  used  in  structurally  complex  environments.  This  conclusion  will  require  further 
validation  on  ever  increasingly  complex  test  specimens  (see  figure  4.14) 


Figure  4.14:  Possible  Specimens  for  Future  Sensor  Testing 
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The  next  conclusion  suggested  by  the  results  is  that  the  simulated  damage 
methods  employed  by  this  thesis  group  do  not  provide  a  good  indication  of  sensor 
performance  with  respect  to  actual  damage.  The  most  likely  reason  for  this  is  that  the 
magnitude  of  change  induced  by  the  blocks  is  far  greater  than  the  magnitude  of  change 
produced  by  the  actual  damage  inflicted.  This  is  not  to  say  that  there  is  no  good 
simulated  damage  method  to  be  found,  but  the  one  used  for  this  thesis  was  not  viable. 

The  result  with  the  most  potential  for  affecting  future  efforts  is  the  fact  that  overall 
properties  of  the  test  specimen  affect  the  performance  of  the  sensor.  Once  again,  this 
makes  intuitive  sense  but  the  reality  of  the  situation  is  much  more  complex.  This  result 
calls  into  question  the  methodology  of  starting  simple  and  building  up  the  structural 
complexity  of  the  test  specimen.  It  is  entirely  possible  that  the  sensor  locations, 
frequencies  and  possibly  even  the  wave  fonns  that  worked  in  the  initial  element  will  not 
be  capable  of  working  in  the  altered  element.  The  potential  result  is  that  a  great  deal 
more  effort  is  spent  constructing  the  test  specimen  to  more  closely  resemble  the  actual 
structure  in  question.  Only  then  can  the  sensor  location,  operating  frequencies,  and  wave 
forms  be  optimized  for  the  real  environment.  A  final  area  of  consideration  has  to  do  with 
data  processing  and  the  treatment  of  background  noise.  Since  damage  detection  using 
Lamb  waves  is  based  on  comparative  data  analysis,  significant  work  must  be 
accomplished  to  gather  and  correlate  baseline  data  from  the  system  to  use  for 
comparison.  Our  research  has  shown  that  baseline  data,  while  fairly  consistent,  is  subject 
to  many  variables,  and  can  easily  overwhelm  the  desired  damage  signatures  in  the  data. 
Our  research  did  not  employ  any  kind  of  filtering  or  long  term  data  averaging.  Data 
analysis  was  conducted  using  an  average  of  the  previous  baseline  data  (2  or  3  separate 


68 


data  sets).  Multiple  runs  of  the  same  test  condition  were  conducted  and  compared.  For 
the  most  part,  the  results  of  these  “identical”  runs  were  consistent,  but  not  in  every  case, 
especially  if  the  runs  were  conducted  on  different  days.  Obviously  the  area  of  data 
fdtering  and  rules  for  conducting  the  actual  data  comparisons  needs  to  be  explored  more 
fully.  In  the  end,  this  thesis  group  feels  as  if  we  have  advanced  the  understanding  of  the 
capability  of  this  sensor  package,  as  well  as  identified  several  areas  which  require  further 
study. 
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V.  Recommendations  for  Further  Research  and  Conclusion 


This  chapter  summarizes  the  conclusions  of  the  group  regarding  the  architectures 
and  processes  developed.  It  also  provides  suggestions  for  avenues  of  further  research  in 
a  variety  of  areas. 

5.1  Suggestions  For  Further  Research  With  METIS  Sensor 

Although  the  thesis  group  was  able  to  test  two  generations  of  sensors  on  a  single 
test  specimen  in  a  multitude  of  ways,  the  action  of  actually  damaging  the  specimen  limits 
the  number  of  tests  that  can  be  performed  on  a  single  specimen.  Further  testing  needs  to 
be  conducted  on  additional  specimens  in  order  to  refine  the  capabilities  of  the  METIS 
sensors.  Suggestions  for  additional  testing  include  different  size  plates,  different 
thicknesses,  more  complex  geometries,  additional  frequencies,  different  amplitudes, 
different  materials,  and  damage  at  different  locations.  Additional  research  could  be 
undertaken  in  order  to  determine  the  minimum  size  damage  that  can  be  detected.  Studies 
need  to  be  performed  that  examine  whether  different  frequencies  are  optimal  for  different 
types  of  damage,  or  different  materials.  Ideally,  one  optimal  frequency  could  be  used  for 
each  structural  area  on  an  aircraft  instead  of  having  to  do  frequency  sweeps  like  the  thesis 
group.  The  capabilities  of  the  METIS  sensors  were  limited  during  this  thesis  to  the  use 
of  two  nodes  in  the  pitch-catch  mode  and  further  research  can  be  explored  to  expand  the 
capabilities  to  multiple  nodes  where  potentially  a  network  of  nodes  can  be  used. 
Additionally,  the  size  and  wiring  of  METIS  sensors  could  make  their  use  in  an  actual 
aircraft  complicated,  therefore  research  can  be  done  to  reduce  the  disk  size  and  explore 
the  use  of  wireless  technology  in  transmitting  data. 
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5.2  Suggestions  For  Further  Research  With  Software 

The  thesis  group  relied  on  rather  basic  methods  of  data  manipulation  and  filtering 
in  order  to  analyze  the  data.  A  very  wide  avenue  that  needs  to  be  explored  further  for 
structural  health  monitoring  is  the  software  aspect.  The  thesis  group  found  that  one  of 
the  most  significant  challenges  in  operating  the  ISHMS  was  the  sheer  magnitude  and 
complexity  of  data.  The  thesis  group  used  Microsoft  Excel  and  some  basic  MatLab  code 
to  analyze  the  data  using  simple  comparative  analysis.  There  is  tremendous  potential  in 
using  software  to  accomplish  data  manipulation  and  filtering  automatically.  Computer 
programs  that  can  filter  out  the  important  aspects  of  data  and  automatically  compare  them 
to  other  programs  would  be  vital  to  successfully  monitoring  the  structural  health  of  an 
aircraft  fleet.  These  programs  could  potentially  make  it  much  simpler  for  the  engineer  to 
make  recommendations. 

5.3  Additional  Suggestions  For  Further  Research 

Finally,  although  the  thesis  group  chose  to  experiment  with  the  METIS  sensor, 
there  are  many  other  technologies  that  exist  that  could  monitor  structural  health.  Another 
approach  can  be  to  select  an  entirely  different  technology  to  study  from  among  those 
currently  available  or  a  new  emerging  technology,  or  even  select  several  different 
technologies  to  be  studied  and  packaged  together  that  can  provide  multiple  capabilities. 
The  generic  process  created  by  the  thesis  group  can  then  be  used  as  a  guideline  to 
integrate  these  technologies  into  an  aircraft.  Finally,  another  emerging  area  in  structural 
health  is  the  desire  for  real-time  structural  health  monitoring.  As  technology  improves, 
research  can  be  done  into  an  ISHMS  that  can  provide  real  time  data  or  warning  system 
inside  cockpit  for  the  crew. 
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5.4  Conclusion 


From  the  beginning,  the  primary  goal  of  the  thesis  group  was  to  create  a  process 
to  develop  a  generic  structural  health  monitoring  system.  This  process  would  enable  the 
user  to  integrate  any  current  or  past  technology  into  a  variety  of  applications.  The 
process  would  be  flexible  enough  to  account  for  a  variety  of  sensor  systems  and 
structural  areas.  Through  the  development  of  an  actual  structural  health  monitoring 
system,  the  thesis  group  was  able  to  validate  significant  steps  of  the  process.  The 
development  of  the  structural  health  monitoring  system  shows  that  system  requirements 
can  be  translated  into  an  operational  system  with  damage  detection  capability.  In 
addition,  the  thesis  group  proved  the  potential  of  the  METIS  sensor  package  for  structural 
health  monitoring  applications.  Although  the  thesis  group  only  had  the  time  and 
resources  to  run  a  limited  test  regime,  the  group  concluded  that  the  technology  is 
applicable  for  structural  problems  and  that  further  research  should  be  conducted  to 
improve  the  knowledge  base  for  the  METIS  sensors.  With  additional  time  and  resources, 
the  thesis  group  is  confident  that  the  METIS  sensors,  applicable  software  and  data 
processing  resources  could  be  integrated  into  a  functional  structural  health  monitoring 
system  able  to  meet  the  user  needs. 
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Appendix  A.  Integrated  Data  Dictionary  ( AV-2 ) 


OPERATIONAL  ACTIVITIES: 

Operational  Activity:  Analyze  Data 

Glossary  Text:  Data  Analysis  includes  all  activities  related  to  detailed  analysis  of  the 
processed  data.  This  includes  drawing  conclusions  and  recommendations  from 
the  processed  data  relevant  to  a  specific  structural  problem. 

Operational  Activity:  Analyze  Reports 

Glossary  Text:  Consists  of  an  overall  analysis  of  mission,  aircraft  and  fleet  reports  to 
ensure  data  integrity. 

Operational  Activity:  Collect  Data 

Glossary  Text:  Consists  of  the  sensor  perfonning  the  structural  monitoring  test  and 
collecting  the  data  in  raw  form 

Operational  Activity:  Collect  /  Store  Data 

Glossary  Text:  Data  collection  includes  utilizing  sensors  to  record  raw  data  from  sample 
of  interest  and  storing  it. 

Operational  Activity:  Compile  Flight  Data 

Glossary  Text:  Filter  out  bad  data  and  correlate  raw  data  with  mission  parameters 

Operational  Activity:  Define  ISHM  System  Requirements 

Glossary  Text:  Consists  of  all  actions  taken  to  define  the  system  requirements.  May 
include  Operational,  Maintenance,  Sensor  and  Data  requirements. 

Operational  Activity:  Design  Data  Collection  Device 

Glossary  Text:  Design  the  ISHM  Data  Collection  Device  to  meet  the  Data  Collection 
Requirements. 

Operational  Activity:  Design  Data  Processing  Software 

Glossary  Text:  Design  the  ISHM  Data  Processing  Software  to  meet  the  Data  Collection 
Requirements. 

Operational  Activity:  Design  Sensors 

Glossary  Text:  Design  ISHM  Sensors  to  meet  the  sensor  requirements. 
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Operational  Activity:  Design  ISHM  System 

Glossary  Text:  Consists  of  all  actions  taken  to  design  and  acquire  the  system.  May 
include  sensors,  data  collection  device,  software  and  engineers. 

Operational  Activity:  Determine  Accessibility 

Glossary  Text:  Ease  of  access  to  the  structural  health  monitoring  system  components. 

Operational  Activity:  Determine  Analysis  Requirements 

Glossary  Text:  Determine  the  necessary  engineering  skills  and  needs  to  interpret  the  data 
into  usable  recommendations. 

Operational  Activity:  Determine  Concept  of  Operations 

Glossary  Text:  Determine  the  concept  of  operation  for  the  ISHM  System.  Will  include 
how  often  sensors  take  readings,  how  often  data  is  collected  and  analyzed,  and 
procedures  for  taking  maintenance  action. 

Operational  Activity:  Determine  Data  Requirements 

Glossary  Text:  Determine  the  requirements  for  the  data  collection  and  processing 
components  of  the  ISHM  System. 

Operational  Activity:  Determine  Durability 

Glossary  Text:  The  capabilities  of  the  structural  health  monitoring  system  to  sustain 
damage  and  severe  environments. 

Operational  Activity:  Determine  Maintainability 

Glossary  Text:  The  ease  in  which  the  system  is  repaired. 

Operational  Activity:  Determine  Maintenance  Requirements 

Glossary  Text:  Determine  the  requirements  for  the  maintenance  of  the  ISHM  System. 
May  include,  maintainability,  reliability,  availability,  accessibility,  etc. 

Operational  Activity:  Determine  Sensor  Locations 

Glossary  Text:  Determine  the  location  of  sensors  based  on  crack  history,  critical 
locations,  or  engineer  recommendation. 

Operational  Activity:  Determine  Sensor  Properties 

Glossary  Text:  Determine  the  necessary  sensor  properties  such  as  temperature  range, 
accuracy,  frequency,  size,  sampling  rate,  etc. 

Operational  Activity:  Determine  Sensor  Quantity 

Glossary  Text:  Determine  the  number  of  sensors  required  to  cover  an  area  of  interest. 

Operational  Activity:  Determine  Size  Requirements 

Glossary  Text:  Determine  the  size  requirements  of  the  ISHM  System. 
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Operational  Activity:  Determine  Monitoring  Requirements 

Glossary  Text:  Determine  the  requirements  for  the  sensor  components  of  the  ISHM 
System. 

Operational  Activity:  Determine  Operational  Requirements 

Glossary  Text:  Determine  the  operational  requirements  for  the  ISHM  System.  May 
include  operational  concept,  environmental  factors,  etc. 

Operational  Activity:  Determine  Processing  Requirements 

Glossary  Text:  Determine  the  necessary  data  processing  requirements.  Includes  level  of 
automation,  output  fonnat,  etc. 

Operational  Activity:  Determine  Reliability 

Glossary  Text:  The  probability  that  a  system  will  malfunction  in  a  specified  period  of 
time. 

Operational  Activity:  Determine  Storage  Requirements 

Glossary  Text:  Determine  the  necessary  amount  of  data  storage  for  applicable 
information. 

Operational  Activity:  Determine  System  Health  Performance 

Glossary  Text:  Consists  of  actions  taken  to  determine  the  health  of  the  ISHM  System. 
These  may  be  in  the  fonn  of  self-diagnostics  or  inspections 

Operational  Activity:  Determine  Temperature  Requirements 

Glossary  Text:  Determine  the  temperature  requirements  of  the  ISHM  System. 

Operational  Activity:  Determine  Vibration  Requirements 

Glossary  Text:  Determine  the  vibration  requirements  of  the  ISHM  System. 

Operational  Activity:  Generate  A/C  Maintenance  Actions 

Glossary  Text:  Consists  of  maintenance  actions  to  repair  or  replace  damage  structure. 

Operational  Activity:  Generate  Flight  Restrictions 

Glossary  Text:  Consists  of  adding  or  changing  flight  restrictions  to  prevent  further  or 
additional  structural  damage. 

Operational  Activity:  Generate  Maintenance  Action 

Glossary  Text:  Consists  of  maintenance  action  required  on  the  actual  structural  health 
monitoring  system,  including,  sensors,  power,  data  acquisition,  etc. 
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Operational  Activity:  Install  Data  Collection  Device 

Glossary  Text:  Install  the  data  collection  device  onto  the  aircraft  in  accordance  with  the 
data  collection  plan. 

Operational  Activity:  Install  ISHM  System 

Glossary  Text:  Consists  of  all  actions  taken  to  install  the  ISHM  System.  May  include 
installing  sensors,  data  collection  device  and  software. 

Operational  Activity:  Install  Sensors 

Glossary  Text:  Install  sensors  onto  the  aircraft  in  accordance  with  the  sensor  selection 
plan. 

Operational  Activity:  Install  Software 

Glossary  Text:  Install  necessary  ISHM  System  software  in  accordance  with  the  data 
collection  plan. 

Operational  Activity:  Monitor  Structural  Health 

Glossary  Text:  Consists  of  all  actions  and  components  necessary  in  monitoring  the 
structural  health  of  an  aircraft. 

Operational  Activity:  Operate  ISHM  System 

Glossary  Text:  Consists  of  all  activities  accomplished  in  the  nonnal  operation  of  an 

integrated  structural  health  monitoring  systems.  Includes  data  collection,  analysis 
and  processing. 

Operational  Activity:  Process  Data 

Glossary  Text:  Data  Processing  includes  all  activities  required  to  transfonn  the  raw  data 
into  usable  information,  such  as  charts  and/or  tables. 

Operational  Activity:  Recommend  Action 

Glossary  Text:  Consists  of  recommended  actions  to  accomplish  to  the  aircraft  or  fleet 
based  on  the  discovery  of  a  structural  problem. 

Operational  Activity:  Run  Aircraft  Historical  Processing 

Glossary  Text:  Filtered  data  is  compared  against  historical  aircraft  records  to  determine  if 
any  new  structural  damage  is  present. 

Operational  Activity:  Run  Detailed  Analysis 

Glossary  Text:  Consists  of  detailed  analysis  of  data  to  determine  if  a  structural  problem 
exists.  Includes  information  such  as  type,  size,  location  and  criticality. 
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Operational  Activity:  Run  Fleet  Historical  Processing 

Glossary  Text:  Filtered  data  is  compared  against  historical  fleet  records  to  determine  if 
new  structural  damage  is  present  and  determine  if  any  fleet  wide  trends  are 
emerging 

Operational  Activity:  Run  Mission  Processing 

Glossary  Text:  Filtered  Data  is  run  against  mission  parameters  to  determine  if  any 
structural  damage  is  present  as  a  result  of  the  mission. 

Operational  Activity:  Run  Trend  Analysis 

Glossary  Text:  Consists  of  detailed  analysis  of  mission,  aircraft  and  fleet  trends  to 
determine  if  a  specific  action  is  the  cause  of  a  structural  problem. 

Operational  Activity:  Store  Data 

Glossary  Text:  Consists  of  storing  the  raw  data  taken  from  the  sensor  to  retrieve  at  a  later 
time. 

Operational  Activity:  Train  Engineers 

Glossary  Text:  Train  engineers  in  accordance  with  engineer  requirements. 

Operational  Activity:  Update  Inspection  Requirements 

Glossary  Text:  Consists  of  adding  on  changing  aircraft  or  fleet  inspection  requirements 
based  on  damage. 

Operational  Activity:  Utilize  Results 

Glossary  Text:  Utilizing  the  results  involves  taking  the  recommendations  generated  from 
the  data  analysis  and  perfonning  the  action  on  the  specific  structural  area.  This 
may  include  an  inspection,  repair,  or  other  maintenance  action. 


ICOMS: 

ICOM  line:  Aircraft  Design 

Glossary  Text:  Consists  of  the  physical  design  of  the  aircraft  including  size  and  space 
dimensions. 

ICOM  line:  Aircraft  Structural  Health  Report 

Glossary  Text:  Consists  of  detailed  infonnation  regarding  the  specific  structural  test 
reported  in  a  format  that  will  be  understood  to  the  trained  user.  Consists  of 
graphs,  charts,  and  historical  information  about  the  aircraft  and  fleet. 

ICOM  line:  Analysis  Results 

Glossary  Text:  Consists  of  the  results  drawn  from  the  processed  data.  Includes 
recommendations  on  actions  to  take  relative  to  the  subject  material. 
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ICOM  line:  Completed  Structural  Health  Maintenance  Action 

Glossary  Text:  Consists  of  completion  of  the  recommended  maintenance  action,  flight 
restriction  or  inspection  procedure. 

ICOM  line:  Cost  /  Budget 

Glossary  Text:  Consists  of  the  money  available  to  fund  the  ISHM  System. 

ICOM  line:  Data  Collection  Device 

Glossary  Text:  Consists  of  the  Data  Collection  Device  for  the  ISHM  System 

ICOM  line:  Data  Collection  Plan 

Glossary  Text:  Consists  of  a  detailed  plan  on  what  technology  the  data  collection  devices 
are,  and  how  they  will  be  positioned  and  used. 

ICOM  line:  Data  Collection  Requirements 

Glossary  Text:  Consists  of  the  data  requirements  necessary  for  a  functional  ISHM 
System.  Includes  data  format,  storage,  bandwidth,  etc. 

ICOM  line:  Data  Request 

Glossary  Text:  A  Request  for  data  to  be  sent. 

ICOM  line:  Engineer  Requirements 

Glossary  Text:  Consists  of  the  engineer  requirements  necessary  for  a  functional  ISHM 
System.  Includes  training,  processes,  and  structural  knowledge. 

ICOM  line:  Engineering  Expertise 

Glossary  Text:  Trained  Engineers  that  are  required  to  interpret  the  processed  data  into 
actual  maintenance  recommendations. 

ICOM  line:  Engineers 

Glossary  Text:  Consist  of  a  team  of  experts  that  are  familiar  with  the  design  of  the 
aircraft. 

ICOM  line:  Environment 

Glossary  Text:  Consists  of  things  that  may  be  beyond  the  user's  control.  May  include, 
temperature,  vibration,  acoustics,  exposure  to  elements,  size  of  area,  etc. 

ICOM  line:  Filtered  Data 

Glossary  Text:  Consists  of  data  that  has  been  filtered  to  show  relevant  parameters  and 
information. 

ICOM  line:  Flight  Parameters 

Glossary  Text:  Consists  of  flight  parameters  for  a  specific  mission. 
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ICOM  line:  Flight  Profile 

Glossary  Text:  Consists  of  flight  parameters  that  the  aircraft  is  able  and  expected  to 
perform  over  its  life. 

ICOM  line:  Historical  Data 

Glossary  Text:  Consists  of  historical  data  concerning  the  structural  history  of  the  specific 
aircraft,  or  fleet  of  aircraft. 

ICOM  line:  Maintenance  Practices 

Glossary  Text:  Consists  of  common  practices  for  the  specific  aircraft.  May  include 

things  such  as  how  often  an  area  is  accessed  for  maintenance  and  what  inspection 
procedures  and  intervals  the  ISHM  System  would  have. 

ICOM  line:  Maintenance  Requirements 

Glossary  Text:  Consists  of  the  maintenance  requirements  necessary  for  a  functional 
ISHM  System.  May  include,  maintainability,  reliability,  availability, 
accessibility,  etc. 

ICOM  line:  Maintainers 

Glossary  Text:  Consists  of  the  personnel  that  maintain  the  aircraft  and  the  ISHM  System. 

ICOM  line:  Operational  Requirements 

Glossary  Text:  Consists  of  the  operational  requirements  necessary  for  a  functional  ISHM 
System.  Includes  operational  concept,  environmental  factors,  etc. 

ICOM  line:  Operational  Data  Collection  Device 

Glossary  Text:  Data  Collection  devices  that  are  fully  operational  and  prepared  to  store 
and  process  data. 

ICOM  line:  Operational  Sensors 

Glossary  Text:  Sensors  that  are  fully  operational  and  prepared  to  measure  data. 

ICOM  line:  Operational  Software 

Glossary  Text:  Software  that  is  fully  operational  and  prepared  to  process  data. 

ICOM  line:  Raw  Data 

Glossary  Text:  Consists  of  data  in  unmodified  terms.  It  is  simply  the  raw  numbers 
recorded  by  the  sensor. 

ICOM  line:  Recommended  Maintenance  Action 

Glossary  Text:  Consists  of  recommendations  on  further  action  regarding  the  structural 
member  of  interest.  They  may  include  flight  restrictions,  inspection  procedures, 
intervals,  or  repair  procedures. 
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ICOM  line:  Sensor  Properties 

Glossary  Text:  Consists  of  properties  such  as  temperature  range,  accuracy,  frequency, 
size,  sampling  rate,  etc. 

ICOM  line:  Sensor  Requirements 

Glossary  Text:  Consists  of  the  sensor  requirements  necessary  for  a  functional  ISHM 
System.  Includes  frequency,  location,  size,  sampling  rates,  quantity,  etc. 

ICOM  line:  Sensor  Selection  Plan 

Glossary  Text:  Consists  of  a  detailed  plan  on  what  technology  the  sensors  are,  and  how 
they  will  be  positioned  and  used. 

ICOM  line:  Sensors 

Glossary  Text:  Consists  of  the  sensors  and  wiring  that  make  up  the  ISHM  System 

ICOM  line:  Stakeholder  Input 

Glossary  Text:  Consists  of  input  from  stakeholders  such  as  user,  engineering  support, 
designer,  or  maintainer. 

ICOM  line:  Stakeholders 

Glossary  Text:  Consists  of  the  group  of  people  that  have  an  interest  in  the  ISHMS 
system.  May  include  engineers,  maintainers,  budget  personnel,  etc. 

ICOM  line:  Software 

Glossary  Text:  Consists  of  the  Processing  and  Database  Software  for  the  ISHM  System 

ICOM  line:  System  Health  Report 

Glossary  Text:  Consists  of  an  assessment  on  system  health  based  on  self-diagnostic 
readings  and  analysis  of  data  reported. 

ICOM  line:  Technology 

Glossary  Text:  Consists  of  the  actual  technologies  used  by  the  ISHM  System  including, 
sensors,  data  collection  devices  and  processing  software. 

ICOM  line:  Test  Completion 

Glossary  Text:  Consists  of  a  signal  that  the  test  has  completed. 

ICOM  line:  Test  Initiation 

Glossary  Text:  The  action  that  is  taken  to  generate  a  test  on  a  specific  aircraft  structural 
component. 
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Appendix  B.  First  Generation  Sensor  Test  Plots 


Pulse-Echo  (Sensor  0072):  08  Nov  06,  Block  1  @  6”  and  0°,  No  Damage  Baseline 


Pulse-Echo:  35  kHz  Sensor  0072  Pulse-Echo  (0072):  35kHz  (No  Damage  Average  -  08  Nov  Block  1)  Delta 
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Pulse-Echo  (0072):  65kHz  (No  Damage  Average  -  08  Nov  Block  1)  Delta 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  -  08  Nov  Baseline)  Delta 


0.0006 


Pulse-Echo:  95kHz  Sensor  0072  Pulse-Echo  (0072):  95kHz  (No  Damage  Average  -  08  Nov  Block  1)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  6 


7  726  755  784 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  4 


5  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  -  08  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 
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Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  -  08  Nov  Block  1)  Delta 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  -  08  Nov  Baseline)  Delta 


„ l 
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i 

! 
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J 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (Sensor  0072):  08  Nov  06,  Block  2  @  6”  and  0°,  No  Damage  Baseline 
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Pulse-Echo  (0072):  35kHz  (No  Damage  Average  -  08  Nov  Baseline)  Delta 


Pulse-Echo:  65kHz  Sensor  0072 


Time  Increment  Time  Increment 

Pulse-Echo  (0072):  65kHz  (No  Damage  Average  -  08  Nov  Block  2)  Delta  Pulse-Echo  (0072):  65kHz  (No  Damage  Average  -  08  Nov  Baseline)  Delta 


0.0005 


Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  -  08  Nov  Block  2)  Delta 


85 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  -  08  Nov  Block  2)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  -  08  Nov  Baseline)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784  1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 

Time  Increment  Time  Increment 


Pulse-Echo:  155kHz  Sensor  0072  Pulse-Echo  (0072):  155kHz  (No  Damage  Average  -  08  Nov  Block  2)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784  1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 

Time  Increment  Time  Increment 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  -  08  Nov  Baseline)  Delta 


1 

0.0006  - 

| 

J 

Pulse-Echo  (Sensor  0072):  10  Nov  06,  Block  1  @  16”  and  0°,  No  Damage  Baseline 
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Pulse-Echo:  35  kHz  Sensor  0072 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Block  1)  Delta 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Block  1)  Delta 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 
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Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Block  1)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Block  1)  Delta 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 
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Pulse-Echo:  35  kHz  Sensor  0072 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Block  2)  Delta 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Block  2)  Delta 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 
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Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Block  2)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Block  2)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Block  2)  Delta 


0.0016 
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Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo  (Sensor  0072):  10  Nov  06,  Block  2  @  6”  and  90°,  Angled  45°,  No  Damage 
Baseline 


Pulse-Echo:  35  kHz  Sensor  0072 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Block  2  Run2)  Delta 
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Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  2)  Delta 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  2)  Delta 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 


J 

III  1  II  1 

fMikw 

Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  2)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 
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Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  2)  Delta 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo  (Sensor  0072):  10  Nov  06,  Block  2  @  6”  and  0°,  Short  Edge,  No  Damage  Baseline 


■ 


Pulse-Echo:  35  kHz  Sensor  0072 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  3)  Delta 
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Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  65kHz  Sensor  0072 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  3)  Delta 


94 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  3)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  3)  Delta 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo  (Sensor  0072):  10  Nov  06,  Block  2  @  10.5”  and  0°,  No  Damage  Baseline 
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Pulse-Echo:  35  kHz  Sensor  0072 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  4)  Delta 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


a 

> 

1 II  1  1— 1 "H 

1  30 


59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  4)  Delta 
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Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  4)  Delta 


Pulse-Echo:  155kHz  Sensor  0072 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Block  2  Run  4)  Delta 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 
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59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  6 


7  726  755  784 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Block  8)  Delta 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


7  726  755  784 


Pulse-Echo:  65kHz  Sensor  0072 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 
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Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Block  8)  Delta 


11 

|C|-—  Average  No  Damage  Baseline  1 
|  - Block  8  @  6  inches  0  deg  10  Nov  | 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Block  8)  Delta 


Pulse-Echo:  155kHz  Sensor  0072 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  £ 


7  726  755  784 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Block  8)  Delta 
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Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo  (Sensor  0072):  10  Nov  06,  Block  2  @  6”  and  0°,  Block  1  @  16”  and  0° 
No  Damage  Baseline  _ _ 


Pulse-Echo:  35  kHz  Sensor  0072 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  65kHz  Sensor  0072 


100 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Block  1  &  2)  Delta 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  95kHz  Sensor  0072 


11 

- Average  No  Damage  Baseline 

- Block  1  @  1 6  inches  0  deg  Block  2  1 

1  @  6  inches  0  deg  10  Nov 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Block  1  &  2)  Delta 

0.0007  - 


0.1 


0.0005 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Block  1  &  2)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 
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Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Block  1  &  2)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (Sensor  0072):  10  Nov  06,  Block  2  @  6”  and  90°,  Block  1  @  16”  and  0° 
No  Damage  Baseline 


Pulse-Echo:  35  kHz  Sensor  0072 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Block  1  &  2  Run  2) 
Delta 

0.0008  - 


0.1 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  £ 


7  726  755  784 
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Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  65kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 
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Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Block  1  &  2  Run  2) 
Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 10  Nov  Baseline)  Delta 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 10  Nov  Block  1  &  2  Run  2) 
Delta 


Pulse-Echo  (Sensor  0072):  16  Nov  06,  Block  1  @  165mm  and  0°,  No  Damage  Baseline 
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Pulse-Echo:  35  kHz  Sensor  0072 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 16  Nov  Block  1)  Delta 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 


Pulse-Echo:  65kHz  Sensor  0072 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 16  Nov  Block  1)  Delta 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 
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Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 16  Nov  Block  1)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  6 


8  697  726  755  784 
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Pulse-Echo:  35  kHz  Sensor  0072  Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 16  Nov  Block  2)  Delta 
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Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 16  Nov  Block  2)  Delta 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  6 


8  697  726  755  784 
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Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 16  Nov  Block  2)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  6 


7  726  755  784 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581 


697  726  755  784 
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Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (Sensor  0072):  16  Nov  06,  Block  2  @  433mm  and  0°,  No  Damage  Baseline 
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Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 16  Nov  Block  2  Run  2)  Delta 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 
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Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 16  Nov  Block  2  Run  2)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (Sensor  0072):  16  Nov  06,  Block  1 
No  Damage  Baseline 


165mm  and  0°,  Block  2  (51  433mm  and  0° 
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Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 


Pulse-Echo:  65kHz  Sensor  0072 


Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 16  Nov  Block  1  &  2)  Delta 


0.0007 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 
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Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 16  Nov  Block  1  &  2)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 
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B  697  726  755  784 


Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 16  Nov  Block  1  &  2)  Delta 


0.145 


0.115 


1  30  59 


88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 16  Nov  Baseline)  Delta 


5 

1 

0.0004  - 

4 

o-31 

| 
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Pulse-Echo  (Sensor  0072):  21  Nov  06,  Block  2  @  165mm  and  0°,  No  Damage  Baseline 
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Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  -  21  Nov  Block  2)  Delta 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  -  21  Nov  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 
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Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  -  21  Nov  Block  2)  Delta 


114 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  -21  Nov  Baseline)  Delta 
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Pulse-Echo  (0072):  125kHz  (No  Damage  Average  -  28  Nov  Block  10)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  -  28  Nov  Baseline)  Delta 


Pulse-Echo  (Sensor  0072):  28  Nov  06,  Block  10  @  165mm  and  90°,  No  Damage  Baseline 
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Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  -  28  Nov  Block  10  Run  2)  Delta 
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Pulse-Echo  (0072):  155kHz  (No  Damage  Average  -28  Nov  Baseline)  Delta 


Pulse-Echo  (Sensor  0072):  30  Nov  06,  Block  10  (5)  165mm  and  180°,  No  Damage  Baseline 


Pulse-Echo:  95kHz  Sensor  0072  Pulse-Echo  (0072):  95kHz  (No  Damage  Average  -  30  Nov  Block  10)  Delta 
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Pulse-Echo  (0072):  125kHz  (No  Damage  Average  -  30  Nov  Block  10)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  -  30  Nov  Baseline)  Delta 
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Pulse-Echo:  35  kHz  Sensor  0072 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 13  Dec  Damage  One)  Delta 


Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 13  Dec  Baseline)  Delta 


Pulse-Echo:  65kHz  Sensor  0072 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 13  Dec  Baseline)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 13  Dec  Damage  One)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581 


697  726  755  784 
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Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 13  Dec  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 


0.0006 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 13  Dec  Damage  One)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 13  Dec  Baseline)  Delta 
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Pulse-Echo  (Sensor  0072):  14  Dec  06,  3mm  Gouge  @  165mm  and  0°,  No  Damage  Baseline 

Pulse-Echo:  35  kHz  Sensor  0072  Pulse-Echo  (0072):  35kHz  (No  Damage  Average  - 14  Dec  Damage  One)  Delta 


4 

- - 

vl 

nr 

I - Average  No  Damage  Baseline  1 

H - Damage  One  -  3mm  Gouge  14  Dec| 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (0072):  65kHz  (No  Damage  Average  - 13  Dec  Baseline)  Delta 


Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 14  Dec  Damage  One)  Delta 
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Pulse-Echo  (0072):  95kHz  (No  Damage  Average  - 13  Dec  Baseline)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 14  Dec  Damage  One)  Delta 


Pulse-Echo  (0072):  125kHz  (No  Damage  Average  - 13  Dec  Baseline)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  ( 


B  697  726  755  784 


Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 14  Dec  Damage  One)  Delta 


Pulse-Echo  (0072):  155kHz  (No  Damage  Average  - 13  Dec  Baseline)  Delta 
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Pulse-Echo  (Sensor  0072):  14  Dec  06,  4mm  Cross  Gouge  @  165mm  and  0° 
Damage  One  Baseline 


Pulse-Echo:  35  kHz  Sensor  0072  Pulse-Echo  (0072):  35kHz  (Damage  One  Average  - 14  Dec  Damage  Two)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo:  65kHz  Sensor  0072 
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Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (Damage  One  Average  - 14  Dec  Damage  Two)  Delta 


Pulse-Echo:  155kHz  Sensor  072 


Pulse-Echo  (0072):  155kHz  (Damage  One  Average  - 14  Dec  Damage  Two)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 
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Pulse-Echo  (0072):  155kHz  (13  Dec  Damage  One  - 14  Dec  Damage  One)  Delta 


Pulse-Echo  (Sensor  0072):  15  Dec  06,  4mm  Cross  Gouge  @  165mm  and  0° 

Damage  One  Baseline 

Pulse-Echo:  35  kHz  Sensor  0072  Pulse-Echo  (0072):  35kHz  (Damage  One  Average  - 15  Dec  Damage  Two)  Delta 


4 

f 

■  I  - Average  Damage  One  Baseline 

HI  - Damage  Two -4mm  Cross  Gouge  15  Dec  |H 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (0072):  35kHz  (13  Dec  Damage  One  - 14  Dec  Damage  One)  Delta 


Pulse-Echo  (0072):  65kHz  (Damage  One  Average  - 15  Dec  Damage  Two)  Delta 


3.0016 

3.0012 

> 

3.0004 
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41 

1 

3 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo:  65kHz  Sensor  0072 


Pulse-Echo  (0072):  65kHz  (13  Dec  Damage  One  - 14  Dec  Damage  One)  Delta 
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Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (Damage  One  Average  - 15  Dec  Damage  Two)  Delta 


Pulse-Echo  (0072):  95kHz  (13  Dec  Damage  One  - 14  Dec  Damage  One)  Delta 


III  ill 
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1 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo:  125kHz  Sensor  0072 


Pulse-Echo  (0072):  125kHz  (Damage  One  Average  - 15  Dec  Damage  Two)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo:  155kHz  Sensor  072 


Pulse-Echo  (0072):  155kHz  (Damage  One  Average  - 15  Dec  Damage  Two)  Delta 
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Pulse-Echo  (0072):  155kHz  (13  Dec  Damage  One  - 14  Dec  Damage  One)  Delta 


Pulse-Echo  (Sensor  0072):  15  Dec  06,  5mm  Partial  Hole  @  165mm  and  0° 
Damage  Two  Baseline 


Pulse-Echo:  35  kHz  Sensor  0072  Pulse-Echo  (0072):  35kHz  (Damage  Two  Average  - 15  Dec  Damage  Three)  Delta 


Pulse-Echo  (0072):  35kHz  (14  Dec  Damage  Two  - 15  Dec  Damage  Two)  Delta 


0.0016 

0.0012 

0.0004 

|  - Delta  | 
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Pulse-Echo:  65kHz  Sensor  0072 
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Pulse-Echo  (0072):  65kHz  (Damage  Two  Average  - 15  Dec  Damage  Three)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  6 


B  697  726  755  784 


Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (Damage  Two  Average  - 15  Dec  Damage  Three)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  ( 


B  697  726  755  784 


Pulse-Echo  (0072):  95kHz  (14  Dec  Damage  Two  - 15  Dec  Damage  Two)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 
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30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (0072):  125kHz  (Damage  Two  Average  - 15  Dec  Damage  Three)  Delta 


Pulse-Echo  (0072):  125kHz  (14  Dec  Damage  Two  - 15  Dec  Damage  Two)  Delta 
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Pulse-Echo:  155kHz  Sensor  0072 


Pulse-Echo  (0072):  155kHz  (Damage  Two  Average  - 15  Dec  Damage  Three)  Delta 


Pulse-Echo  (0072):  155kHz  (14  Dec  Damage  Two  - 15  Dec  Damage  Two)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pulse-Echo  (Sensor  0072):  15  Dec  06,  6mm  Hole  @  165mm  and  0°,  Damage  Two  Baseline 


Pulse-Echo:  35  kHz  Sensor  0072  Pulse-Echo  (0072):  35kHz  (Damage  Two  Average  - 15  Dec  Damage  Four)  Delta 
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Pulse-Echo  (0072):  35kHz  (14  Dec  Damage  Two  - 15  Dec  Damage  Two)  Delta 


Pulse-Echo:  65kHz  Sensor  0072 


Pulse-Echo  (0072):  65kHz  (Damage  Two  Average  - 15  Dec  Damage  Four)  Delta 


Pulse-Echo  (0072):  65kHz  (14  Dec  Damage  Two  - 15  Dec  Damage  Two)  Delta 


Pulse-Echo:  95kHz  Sensor  0072 


Pulse-Echo  (0072):  95kHz  (Damage  Two  Average  - 15  Dec  Damage  Four)  Delta 


Pulse-Echo  (0072):  95kHz  (14  Dec  Damage  Two  - 15  Dec  Damage  Two)  Delta 


Pulse-Echo:  125kHz  Sensor  0072 
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Pulse-Echo  (0072):  125kHz  (Damage  Two  Average  - 15  Dec  Damage  Four)  Delta 


Pulse-Echo  (0072):  125kHz  (14  Dec  Damage  Two  - 15  Dec  Damage  Two)  Delta 


132 


Appendix  C.  Second  Generation  Sensor  Test  Plots 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (No  Damage  Average  -  08  Jan  Block  10)  Delta 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610 


726  755  784 


Pitch-Catch  (5  to  4):  35kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  65kHz  Far  Sensor  (4) 


0.03 

0.025 

0.02 

0.015 

0.01 

| - B„.lin.  D.II,  | 
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Pitch-Catch  (5  to  4):  65kHz  (No  Damage  Average  -  08  Jan  Block  10)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  95kHz  Far  Sensor  (4) 


r  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  95kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  125kHz  Far  Sensor  (4) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  125kHz  (No  Damage  Average  -  08  Jan  Block  10)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


4u*Hwlt|j44|4^ 


r  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  £ 


3  697  726  755  784 
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Pitch-Catch  (5  to  4):  155kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (No  Damage  Average  -  08  Jan  Block  10)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (No  Damage  Average  - 10  Jan  Block  7)  Delta 
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Pitch-Catch  (5  to  4):  35kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  65kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  65kHz  (No  Damage  Average  - 10  Jan  Block  7)  Delta 
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Pitch-Catch  (5  to  4):  95kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  95kHz  (No  Damage  Average  - 10  Jan  Block  7)  Delta 
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1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  95kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  125kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  125kHz  (No  Damage  Average  - 10  Jan  Block  7)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  155kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (No  Damage  Average  - 10  Jan  Block  7)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (Sensor  5  to  4):  16  Jan  07,  Block  7  Centered,  Offset,  Small  Face 
No  Damage  Baseline 
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Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (No  Damage  Average  - 16  Jan  Block  7  Offset)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  65kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  65kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 
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7  726  755  784 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  95kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (No  Damage  Average  - 16  Jan  Block  7  Offset)  Delta 


0.012 


1 

■  ■  pm) 

1  Hi  i 

liii  liiiiiiii  I 

Lf  (||  |  .111  | 

.Af 

'pi  ii  fin  I  f 

II  p  Hi  pi  If 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 
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Pitch-Catch  (5  to  4):  95kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  125kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (No  Dmg  Average  - 16  Jan  Block  7  Offset)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610 


726  755  784 
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Pitch-Catch  (Sensor  5  to  4):  27  Jan  07,  Damage  3  -  3mm  Gouge,  Centered 
No  Damage  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (No  Damage  Average  -  27  Jan  Damage  #3)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (No  Damage  Average  -  27  Jan  Damage  #3)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 
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Pitch-Catch  (5  to  4):  95kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (No  Damage  Average  -  27  Jan  Damage  #3)  Delta 


0.005 


0.004 


Pitch-Catch  (5  to  4):  155kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (No  Damage  Average  -  27  Jan  Damage  #3)  Delta 
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Pitch-Catch  (5  to  4):  155kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610 


726  755  784 


Pitch-Catch  (Sensor  5  to  4):  29  Jan  07,  Damage  3  -  3mm  Gouge,  Centered 
No  Damage  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (No  Damage  Average  -  29  Jan  Damage  #3)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  65kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  95kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (No  Damage  Average  -  29  Jan  Damage  #3)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (No  Damage  Average  -  29  Jan  Damage  #3)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


Pitch-Catch  (5  to  4):  155kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (No  Damage  Average  -  29  Jan  Damage  #3)  Delta 
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Pitch-Catch  (5  to  4):  155kHz  (No  Damage  17  Jan  /  27  Jan)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (Sensor  5  to  4):  29  Jan  07,  Damage  4  -  Punch  Into  Damage  3,  Centered 
Damage  3  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #3  Average  -  29  Jan  Damage  #4)  Delta 
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Pitch-Catch  (5  to  4):  65kHz  (Damage  #3  Average  -  29  Jan  Damage  #4)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #3  27  Jan  /  29  Jan)  Delta 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #3  27  Jan  /  29  Jan)  Delta 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  125kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  155kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #3  Average  -  29  Jan  Damage  #4)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #3  27  Jan  /  29  Jan)  Delta 


0.004 


Pitch-Catch  (Sensor  5  to  4):  30  Jan  07,  Damage 
Damage  3  Baseline 


003 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


4  -  Punch  Into  Damage  3,  Centered 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #3  Average  -  30  Jan  Damage  #4)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #3  27  Jan  /  29  Jan)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


0.012 
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Pitch-Catch  (5  to  4):  65kHz  (Damage  #3  Average  -  30  Jan  Damage  #4)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #3  27  Jan  /  29  Jan)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #3  Average  -  30  Jan  Damage  #4)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #3  27  Jan  /  29  Jan)  Delta 
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Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #3  Average  -  30  Jan  Damage  #4)  Delta 


1 

.  1, 

1.  .nii it.  ii.  i 

1 1|  .  II,  ,|||.  |||  1 

•- •oV'-fVv> 

mu 

1  30  59  88 

117  146  175  : 

I  - Average  Damage  #3  1 

Baseline 

1  - Damage  #4  30  Jan  1 

204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #3  27  Jan  /  29  Jan)  Delta 


Pitch-Catch  (Sensor  5  to  4):  30  Jan  07,  Damage  5  -  5mm  Cross  Gouge,  Centered 
Damage  4  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #4  Average  -  30  Jan  Damage  #5)  Delta 
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Pitch-Catch  (5  to  4):  35kHz  (Damage  #4  29  Jan  /  30  Jan)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610 


726  755  784 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #4  Average  -  30  Jan  Damage  #5)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #4  29  Jan  /  30  Jan)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


B  697  726  755  784 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #4  Average  -  30  Jan  Damage  #5)  Delta 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #4  29  Jan  /  30  Jan)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  125kHz  (Damage  #4  Average  -  30  Jan  Damage  #5)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #4  29  Jan  /  30  Jan)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


7  726  755  784 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  £ 


B  697  726  755  784 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (Sensor  5  to  4):  30  Jan  07  Run  2,  Damage  5  -  5mm  Cross  Gouge,  Centered 
Damage  4  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #4  Average  -  30  Jan  Damage  #5  Run  2) 
Delta 
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Pitch-Catch  (5  to  4):  35kHz  (Damage  #4  29  Jan  /  30  Jan)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #4  Average  -  30  Jan  Damage  #5  Run  2) 
Delta 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #4  29  Jan  /  30  Jan)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  125kHz  (Damage  #4  29  Jan  /  30  Jan)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  6 


7  726  755  784 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  £ 


B  697  726  755  784 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (Sensor  5  to  4):  31  Jan  07,  Damage  6  -  1/16”  Hole,  Centered 
Damage  5  Baseline 
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Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #5  Average  -  31  Jan  Damage  #6)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #5  30  Jan  /  30  Jan  Run  2)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #5  30  Jan  /  30  Jan  Run  2)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


7  726  755  784 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #5  Average  -  31  Jan  Damage  #6)  Delta 
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Pitch-Catch  (5  to  4):  95kHz  (Damage  #5  30  Jan  /  30  Jan  Run  2)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #5  30  Jan  /  30  Jan  Run  2)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #5  Average  -  31  Jan  Damage  #6)  Delta 
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Pitch-Catch  (Sensor  5  to  4):  31  Jan  07  Run  2,  Damage  6  -  1/16”  Hole,  Centered 
Damage  5  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #5  Average  -  31  Jan  Damage  #6  Run  2) 
Delta 


155 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #5  30  Jan  /  30  Jan  Run  2)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #5  Average  -  31  Jan  Damage  #6  Run  2) 
Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 
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Pitch-Catch  (Sensor  5  to  4):  01  Feb  07  ,  Damage  6  -  1/16”  Hole,  Centered 
Damage  5  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #5  Average  -  01  Feb  Damage  #6)  Delta 


1  30 


59 


88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #5  Average  -  01  Feb  Damage  #6)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #5  30  Jan  /  30  Jan  Run  2)  Delta 
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Pitch-Catch  (5  to  4):  95kHz  (Damage  #5  30  Jan  /  30  Jan  Run  2)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


0.004 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #5  Average  -  01  Feb  Damage  #6)  Delta 
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Pitch-Catch  (Sensor  5  to  4):  01  Feb  07,  Damage  7  -  1/4”  Hole,  Centered 
Damage  6  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #6  Average  -  01  Feb  Damage  #7)  Delta 
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Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #6  Average  -  01  Feb  Damage  #7)  Delta 


Pitch-Catch  (5  to  4):  95kHz  (Average  Dmg  #6  31  Jan  /  31  Jan  Run  2/01  Feb) 
Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #6  Average  -  01  Feb  Damage  #7)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Average  Dmg  #6  31  Jan  /  31  Jan  Run  2/01  Feb) 
Delta 
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Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #6  31  Jan  /  31  Jan  Run  2  /  01  Feb) 
Delta 


Pitch-Catch  (Sensor  5  to  4):  01  Feb  07  Run  2,  Damage  7  -  1/4”  Hole,  Centered 
Damage  6  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #6  Average  -  01  Feb  Damage  #7  Run  2) 

Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Dmg  #6  31  Jan  /  31  Jan  Run  2/01  Feb) 
Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


161 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #6  Average  -  01  Feb  Damage  #7  Run  2) 
Delta 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #6  Average  -  01  Feb  Damage  #7  Run  2) 
Delta 
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Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #6  31  Jan  /  31  Jan  Run  2  /  01  Feb) 
Delta 


0.004 


Pitch-Catch  (Sensor  5  to  4):  02  Feb  07,  Damage  7 
Damage  6  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


1/4”  Hole,  Centered 

Pitch-Catch  (5  to  4):  35kHz  (Damage  #6  Average  -  02  Feb  Damage  #7)  Delta 
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Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #6  Average  -  02  Feb  Damage  #7)  Delta 


Pitch-Catch  (5  to  4):  95kHz  (Average  Dmg  #6  31  Jan  /  31  Jan  Run  2/01  Feb) 
Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


0.375 


3 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  £ 


3  697  726  755  784 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #6  Average  -  02  Feb  Damage  #7)  Delta 

o.oi  - 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #6  Average  -  02  Feb  Damage  #7)  Delta 
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Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #6  31  Jan  /  31  Jan  Run  2  /  01  Feb) 
Delta 


Pitch-Catch  (Sensor  5  to  4):  02  Feb  07,  Damage  8  -  5mm  Gouge,  Centered,  100mm  Offset 
Damage  7  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #7  Average  -  02  Feb  Damage  #8)  Delta 
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Pitch-Catch  (5  to  4):  65kHz  (Damage  #7  Average  -  02  Feb  Damage  #8)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Average  Dmg  #7  01  Feb  /  01  Feb  Run  2  /  02  Feb) 
Delta 
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Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #7  Average  -  02  Feb  Damage  #8)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #7  01  Feb  /  01  Feb  Run  2  /  02  Feb) 
Delta 

0.003  - =^— = - 


0.0025 


Pitch-Catch  (Sensor  5  to  4):  02  Feb  07  Run  2,  Damage  8  -  5mm  Gouge,  Centered,  100mm 
Offset,  Damage  7  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #7  Average  -  02  Feb  Damage  #8  Run  2) 

Delta 
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Pitch-Catch  (5  to  4):  65kHz  (Damage  #7  Average  -  02  Feb  Damage  #8  Run  2) 


Pitch-Catch  (5  to  4):  65kHz  (Average  Dmg  #7  01  Feb  /  01  Feb  Run  2  /  02  Feb) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784  1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #7  Average  -  02  Feb  Damage  #8  Run  2) 
Delta 


Pitch-Catch  (5  to  4):  95kHz  (Average  Dmg  #7  01  Feb  /  01  Feb  Run  2  /  02  Feb) 
Delta 

0.003  -p - 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #7  01  Feb  /  01  Feb  Run  2  /  02  Feb) 
Delta 


Pitch-Catch  (Sensor  5  to  4):  03  Feb  07,  Damage  8 
Damage  7  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


5mm  Gouge,  Centered,  100mm  Offset, 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #7  Average  -  03  Feb  Damage  #8)  Delta 


169 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #7  Average  -  03  Feb  Damage  #8)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Average  Dmg  #7  01  Feb  /  01  Feb  Run  2  /  02  Feb) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  £ 


B  697  726  755  784 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #7  Average  -  03  Feb  Damage  #8)  Delta 


170 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #7  Average  -  03  Feb  Damage  #8)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #7  01  Feb  /  01  Feb  Run  2  /  02  Feb) 
Delta 


Pitch-Catch  (Sensor  5  to  4):  03  Feb  07,  Damage  9  -  1/16”  Flole,  Centered,  100mm  Offset 
Damage  8  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #8  Average  -  03  Feb  Damage  #9)  Delta 


171 


Pitch-Catch  (5  to  4):  35kHz  (Average  Dmg  #8  02  Feb  /  02  Feb  Run  2  /  03  Feb) 
Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #8  Average  -  03  Feb  Damage  #9)  Delta 


Pitch-Catch  (5  to  4):  95kHz  (Average  Dmg  #8  02  Feb  /  02  Feb  Run  2  /  03  Feb) 
Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


172 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #8  Average  -  03  Feb  Damage  #9)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Average  Dmg  #8  02  Feb  /  02  Feb  Run  2  /  03  Feb) 
Delta 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


8  697  726  755  784 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  ( 


B  697  726  755  784 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #8  Average  -  03  Feb  Damage  #9)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 

Time  Increment 

Pitch-Catch  (Sensor  5  to  4):  03  Feb  07  Run  2,  Damage  9  -  1/16”  Hole,  Centered,  100mm 
Offset,  Damage  8  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #8  Average  -  03  Feb  Damage  #9  Run  2) 

Delta 


173 


Pitch-Catch  (5  to  4):  35kHz  (Average  Dmg  #8  02  Feb  /  02  Feb  Run  2  /  03  Feb)  Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 

Delta 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #8  Average  -  03  Feb  Damage  #9  Run  2) 
Delta 


Pitch-Catch  (5  to  4):  65kHz  (Average  Dmg  #8  02  Feb  /  02  Feb  Run  2  /  03  Feb) 
Delta 

0.0025  - 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #8  Average  -  03  Feb  Damage  #9  Run  2) 
Delta 

0.004  - 


0.003 


174 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #8  Average  -  03  Feb  Damage  #9  Run  2) 
Delta 


Pitch-Catch  (5  to  4):  125kHz  (Average  Dmg  #8  02  Feb  /  02  Feb  Run  2  /  03  Feb) 
Delta 


175 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #9  Average  -  03  Feb  Damage  #10)  Delta 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #9  Average  -  03  Feb  Damage  #10)  Delta 


0.006 


176 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #9  03  Feb  /  03  Feb  Run  2)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #9  Average  -  03  Feb  Damage  #10)  Delta 


177 


Pitch-Catch  (Sensor  5  to  4):  04  Feb  07,  Damage  10  -  1/4”  Flole,  Centered,  100mm  Offset 
Damage  9  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #9  Average  -  04  Feb  Damage  #10)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #9  03  Feb  /  03  Feb  Run  2)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #9  Average  -  04  Feb  Damage  #10)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Average  Damage  #9  03  Feb  /  03  Feb  Run  2)  Delta 


178 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #9  03  Feb  /  03  Feb  Run  2)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


179 


Pitch-Catch  (Sensor  5  to  4):  04  Feb  07,  Damage  1 1  -  Punch  (Impact),  Centered,  100mm  Offset 
Damage  10  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #10  Average  -  04  Feb  Damage  #11)  Delta 


180 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #10  Average  -  04  Feb  Damage  #11)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #10  Average  -  04  Feb  Damage  #11)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Average  Damage  #10  03  Feb  /  04  Feb)  Delta 


181 


Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #10  03  Feb  /  04  Feb)  Delta 


Pitch-Catch  (Sensor  5  to  4):  04  Feb  07  Run  2,  Damage  1 1  -  Punch  (Impact),  Centered,  100mm 
Offset,  Damage  10  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #10  Average  -  04  Feb  Damage  #11  Run  2) 
Delta 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #10  03  Feb  /  04  Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


182 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #10  Average  -  04  Feb  Damage  #11  Run  2) 
Delta 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #10  03  Feb  /  04  Feb)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


183 


Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #10  03  Feb  /  04  Feb)  Delta 


Pitch-Catch  (Sensor  5  to  4):  05  Feb  07,  Damage  1 1  -  Punch  (Impact),  Centered,  100mm  Offset 
Damage  10  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #10  Average  -  05  Feb  Damage  #11)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #10  03  Feb  /  04  Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #10  Average  -  05  Feb  Damage  #11)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Average  Damage  #10  03  Feb  /  04  Feb)  Delta 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581 


697  726  755  784 


184 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #10  Average  -  05  Feb  Damage  #11)  Delta 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #10  03  Feb  /  04  Feb)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


185 


Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #10  03  Feb  /  04  Feb)  Delta 


Pitch-Catch  (Sensor  5  to  4):  05  Feb  07,  Damage  12  -  1/4”  Hole,  Centered,  100mm  Offset 
Damage  1 1  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #11  Average  -  05  Feb  Damage  #12)  Delta 


186 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #11  Average  -  05  Feb  Damage  #12)  Delta 


0.006 


Pitch-Catch  (5  to  4):  65kHz  (Average  Dmg  #11  04  Feb  /  04  Feb  Run  2  /  05  Feb) 
Delta 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #11  Average  -  05  Feb  Damage  #12)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  125kHz  (Average  Dmg  #11  04  Feb  /  04  Feb  Run  2  /  05  Feb) 
Delta 

0.006  - 


0.005 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  £ 


3  697  726  755  784 


187 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #11  Average  -  05  Feb  Damage  #12)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #11  04  Feb  /  04  Feb  Run  2  /  05  Feb) 
Delta 


Pitch-Catch  (Sensor  5  to  4):  06  Feb  07,  Damage  12  -  1/4”  Flole,  Centered,  100mm  Offset 
Damage  1 1  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #11  Average  -  06  Feb  Damage  #12)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Dmg  #11  04  Feb  /  04  Feb  Run  2  /  05  Feb) 
Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


188 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #11  Average  -  06  Feb  Damage  #12)  Delta 


0.008 


Pitch-Catch  (5  to  4):  65kHz  (Average  Dmg  #11  04  Feb  /  04  Feb  Run  2  /  05  Feb) 
Delta 


189 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #11  Average  -  06  Feb  Damage  #12)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #11  04  Feb  /  04  Feb  Run  2  /  05  Feb) 
Delta 

0.004  - 


Pitch-Catch  (Sensor  5  to  4):  09  Feb  07,  Damage  13 
Offset,  Damage  12  Baseline 


-  5mm  Gouge,  65mm  from  Sensor  5,  No 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #12  Average  -  09  Feb  Damage  #13)  Delta 


Wil 

rW 

m 

V 

i  r  "I 

1  

- Average  Damage 

- Damage  #13  09  F 

>12  Baseline  | 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


190 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


191 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #12  Average  -  09  Feb  Damage  #13)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (Sensor  5  to  4):  1 1  Feb  07,  Damage  13  -  5mm  Gouge,  65mm  from  Sensor  5,  No 
Offset,  Damage  12  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #12  Average  - 11  Feb  Damage  #13)  Delta 


192 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


0.004 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


0.005 


0.004 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  £ 


3  697  726  755  784 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #12  Average  - 11  Feb  Damage  #13)  Delta 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


193 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #12  Average  - 11  Feb  Damage  #13)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (Sensor  5  to  4):  12  Feb  07,  Damage  13  -  5mm  Gouge,  65mm  from  Sensor  5,  No 
Offset,  Damage  12  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #12  Average  - 12  Feb  Damage  #13)  Delta 


194 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


B  697  726  755  784 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


0.003 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #12  Average  - 12  Feb  Damage  #13)  Delta 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


195 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #12  Average  - 12  Feb  Damage  #13)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


d.»4 


Pitch-Catch  (Sensor  5  to  4):  12  Feb  07,  Damage  14  -  2mm  Cut  from  Center  Hole 


Damage  13  Baseline 


196 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #13  Average  - 12  Feb  Damage  #14)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #13  09  Feb  / 11  Feb  / 12  Feb)  Delta 


197 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #13  09  Feb  / 11  Feb  / 12  Feb)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


3  697  726  755  784 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


7  726  755  784 


Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #13  09  Feb  / 11  Feb  / 12  Feb) 
Delta 


198 


Pitch-Catch  (Sensor  5  to  4):  12  Feb  07  Run  2,  Damage  14  -  2mm  Cut  from  Center  Hole 
Damage  13  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #13  Average  - 12  Feb  Damage  #14  Run  2) 

Delta 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  95kHz  (Damage  #13  Average  - 12  Feb  Damage  #14  Run  2) 

Delta 


199 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #13  09  Feb  / 11  Feb  / 12  Feb)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


200 


Pitch-Catch  (Sensor  5  to  4):  06  Feb  07,  Damage  12  w/  Angle,  Damage  12  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Dmg  #12  Average  -  06  Feb  Dmg  #12  w /  Angle)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  65kHz  (Dmg  #12  Average  -  06  Feb  Dmg  #12  w/  Angle)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  95kHz  (Dmg  #12  Average  -  06  Feb  Dmg  #12  w/  Angle)  Delta 


201 


Pitch-Catch  (5  to  4):  95kHz  (Average  Dmg  #12  05  Feb  /  06  Feb)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


J 
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ip 

1|I  1  T  11 

1 - Average  Damage  #12  Baseline  1 

| - Damage  #1 2  w /  Angle  06  Feb  | 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  125kHz  (Average  Dmg  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Dmg  #12  Average  -  06  Feb  Dmg  #12  w /  Angle)  Delta 


ui.llUlk...Ul,j| 

TF  'I'-JF'l '"w'*  lj 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


7  726  755  784 


Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #12  05  Feb  /  06  Feb)  Delta 
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Pitch-Catch  (Sensor  5  to  4):  07  Feb  07,  Damage  12  w/  Angle,  Damage  12  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Dmg  #12  Average  -  07  Feb  Dmg  #12  w /  Angle)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  65kHz  (Dmg  #12  Average  -  07  Feb  Dmg  #12  w/  Angle)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 
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Pitch-Catch  (5  to  4):  95kHz  (Average  Dmg  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  155kHz  (Dmg  #12  Average  -  07  Feb  Dmg  #12  w /  Angle)  Delta 


I 

1  . 

1, 

ll  llllllll  1  ,1 , 

«*#!*'# M 

p|W| 

1 - Average  Damage  #12  Baseline  1 

1 - Damage  #12  w/  Angle  07  Feb  1, 

1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  155kHz  (Average  Dmg  #12  05  Feb  /  06  Feb)  Delta 
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Pitch-Catch  (Sensor  5  to  4):  08  Feb  07,  Damage  12  w/  Angle,  Damage  12  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Dmg  #12  Average  -  08  Feb  Dmg  #12  w /  Angle)  Delta 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


7  726  755  784 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  65kHz  (Dmg  #12  Average  -  08  Feb  Dmg  #12  w/  Angle)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  05  Feb  /  06  Feb)  Delta 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


726  755  784 


Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Dmg  #12  Average  -  08  Feb  Dmg  #12  w/  Angle)  Delta 
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Pitch-Catch  (5  to  4):  95kHz  (Average  Dmg  #12  05  Feb  /  06  Feb)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #12  w /  Angle  Average  -  08  Feb  Damage  #13 
w /  Angle)  Delta 


697  726  755  784 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  w/Angle  08  Feb  /  09  Feb  / 10 
Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #12  w/  Angle  Average  -  08  Feb  Damage  #13 
w /  Angle)  Delta 
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Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #12  w/ Angle  08  Feb  /  09  Feb  / 10 


7  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  6 


8  697  726  755  784 


Pitch-Catch  (Sensor  5  to  4):  08  Feb  07  Run  2,  Damage  13  w/  Angle 
Damage  12  w/  Angle  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #12  w /  Angle  Average  -  08  Feb  Damage  #13 
w /  Angle  Run  2)  Delta 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581 


726  755  784 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  w/Angle  08  Feb  /  09  Feb  / 10 
Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #12  w /  Angle  Average  -  08  Feb  Damage  #13 
w /  Angle  Run  2)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Average  Damage  #12  w/Angle  08  Feb  /  09  Feb  / 10 
Feb)  Delta 


0.005 


0.004 
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Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #12  w/  Angle  Average  -  08  Feb  Damage  #13 
w /  Angle  Run  2)  Delta 
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Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #12  w/ Angle  08  Feb  /  09  Feb  / 10 
Feb)  Delta 


0.003 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (Sensor  5  to  4):  09  Feb  07,  Damage  13  w/  Angle,  Damage  12  w/  Angle  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4)  Pitch-Catch  (5  to  4):  35kHz  (Damage  #12  w/  Angle  Average  -  09  Feb  Damage  #13 

w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  w/Angle  08  Feb  /  09  Feb  / 10 
Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 
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Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #12  w/  Angle  Average  -  09  Feb  Damage  #13 
w /  Angle)  Delta 


212 


Pitch-Catch  (Sensor  5  to  4):  10  Feb  07,  Damage  13  w/  Angle,  Damage  12  w/  Angle  Baseline 

Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #12  w /  Angle  Average  - 10  Feb  Damage  #13 
w /  Angle)  Delta 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #12  w/Angle  08  Feb  /  09  Feb  / 10 
Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #12  w /  Angle  Average  - 10  Feb  Damage  #13 
w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Average  Damage  #12  w/Angle  08  Feb  /  09  Feb  / 10 
Feb)  Delta 
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Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #12  w/  Angle  Average  - 10  Feb  Damage  #13 
w /  Angle)  Delta 
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Pitch-Catch  (Sensor  5  to  4):  15  Feb  07,  Damage  14  w/  Angle,  Damage  13  w/  Angle  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #13  w/  Angle  Average  - 15  Feb  Damage  #14 
w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run  2 
/  09  Feb/ 10  Feb)  Delta 


Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #13  w /  Angle  Average  - 15  Feb  Damage  #14 
w /  Angle)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  65kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run  2 
/  09  Feb/ 10  Feb)  Delta 
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Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #13  w/ Angle  08  Feb  /  08  Feb  Run  2 
/  09  Feb/ 10  Feb)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #13  w /  Angle  Average  - 15  Feb  Damage 
#14  w /  Angle)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #13  w /  Angle  Average  - 15  Feb  Damage  #14 
w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  125kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run 
2/09  Feb/ 10  Feb)  Delta 
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Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run 
2/09  Feb/ 10  Feb)  Delta 

0.004  - 


Pitch-Catch  (Sensor  5  to  4):  16  Feb  07,  Damage  14  w/  Angle,  Damage  13  w/  Angle  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #13  w /  Angle  Average  - 16  Feb  Damage  #14 
w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run  2  Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 

/  09  Feb/ 10  Feb)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #13  w /  Angle  Average  - 16  Feb  Damage  #14 
w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run  2 
/  09  Feb/ 10  Feb)  Delta 
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Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #13  w/  Angle  Average  - 16  Feb  Damage  #14 
w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #13  w/ Angle  08  Feb  /  08  Feb  Run  2 
/  09  Feb/ 10  Feb)  Delta 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #13  w /  Angle  Average  - 16  Feb  Damage 
#14  w /  Angle)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  125kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run 
2/ 09  Feb/ 10  Feb)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #13  w /  Angle  Average  - 16  Feb  Damage 
#14  w /  Angle)  Delta 


146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581 


697  726  755  784 
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Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run 
2/09  Feb/ 10  Feb)  Delta 

0.004  - 


Pitch-Catch  (Sensor  5  to  4):  19  Feb  07,  Damage  14  w/  Angle,  Damage  13  w/  Angle  Baseline 


Pitch-Catch  (5  to  4):  35  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  35kHz  (Damage  #13  w/  Angle  Average  - 19  Feb  Damage  #14 
w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  35kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run  2  Pitch-Catch  (5  to  4):  65  kHz  Far  Sensor  (4) 

/  09  Feb/ 10  Feb)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Damage  #13  w /  Angle  Average  - 19  Feb  Damage  #14 
w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  65kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run  2 
/  09  Feb/ 10  Feb)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 
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Pitch-Catch  (5  to  4):  95  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Average  Damage  #13  w/ Angle  08  Feb  /  08  Feb  Run  2 
/  09  Feb/ 10  Feb)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  125kHz  (Damage  #13  w /  Angle  Average  - 19  Feb  Damage 
#14  w /  Angle)  Delta 


1  30  59  88  117  146  175  204  233  262  291  320  349  378  407  436  465  494  523  552  581  610  639  668  697  726  755  784 


Pitch-Catch  (5  to  4):  155  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  95kHz  (Damage  #13  w/  Angle  Average  - 19  Feb  Damage  #14 
w /  Angle)  Delta 


Pitch-Catch  (5  to  4):  125  kHz  Far  Sensor  (4) 


Pitch-Catch  (5  to  4):  125kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run 
2/  09  Feb/ 10  Feb)  Delta 


Pitch-Catch  (5  to  4):  155kHz  (Damage  #13  w /  Angle  Average  - 19  Feb  Damage 
#14  w /  Angle)  Delta 
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Pitch-Catch  (5  to  4):  155kHz  (Average  Damage  #13  w/Angle  08  Feb  /  08  Feb  Run 
2/09  Feb/ 10  Feb)  Delta 
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